Encryption & Key Management

The Principle

‍

Encryption is the final guarantee. If every other control fails — if an attacker bypasses authentication, escalates privilege, evades detection, and reaches the data — encryption ensures that what they find is unreadable. A stolen hard drive yields nothing. An intercepted email reveals nothing. A compromised database exports nothing. Encryption does not prevent breach. It prevents consequence.

Ariana Nexus encrypts all data — at rest, in transit, and in use — across every system, device, and communication channel. Encryption is not an optional feature applied to sensitive data. It is the default state of all data within the Ariana Nexus environment. The question is never "should we encrypt this?" The question is "what encryption standard does this data require?"

‍

Encryption Architecture

‍

Encryption at Rest

All data stored within the Ariana Nexus environment is encrypted at rest. Encryption at rest protects data against unauthorized physical access to storage media, including theft of devices, unauthorized access to data centers, and forensic extraction from decommissioned hardware.

Microsoft 365 Service Encryption:

All data stored in Microsoft 365 services — including Exchange Online (email), SharePoint Online (documents and sites), OneDrive for Business (personal file storage), and Microsoft Teams (messages, files, and recordings) — is encrypted at rest using AES-256 (Advanced Encryption Standard with 256-bit keys), one of the strongest symmetric encryption algorithms in commercial use. This encryption is applied automatically by the Microsoft 365 platform at the service layer.

• SharePoint Online and OneDrive: Each file is encrypted with a unique per-file encryption key. Per-file keys are themselves encrypted with a site-level key, which is encrypted with a tenant-level key held in Microsoft's key management infrastructure. This multi-layer key hierarchy ensures that compromise of a single key does not expose all data.
• Exchange Online: Mailbox data is encrypted at the database level using BitLocker and additionally at the service level using Microsoft-managed service encryption keys.
• Microsoft Teams: Messages and files shared in Teams channels are stored in SharePoint and Exchange and inherit their encryption protections.

Endpoint Encryption (Full-Disk):

All company devices — laptops, desktops, and mobile devices — are required to have full-disk encryption enabled and enforced through Microsoft Intune compliance policies:

• Windows Devices: BitLocker Drive Encryption is required and enforced. BitLocker uses AES-128 or AES-256 encryption (Ariana Nexus enforces AES-256 where supported by hardware). Recovery keys are stored securely in Microsoft Entra ID and are accessible only to authorized administrators.
• macOS Devices: FileVault 2 is required and enforced. FileVault uses XTS-AES-128 encryption. Recovery keys are escrowed to Intune.
• Mobile Devices (iOS/Android): Device-level encryption is required as part of the Intune compliance policy. iOS devices use hardware-level AES-256 encryption by default. Android devices are required to have device encryption enabled.
• Compliance Enforcement: Devices that do not have full-disk encryption enabled are marked as non-compliant by Intune and are automatically blocked from accessing Microsoft 365 services by Conditional Access policies. There is no access without encryption.

Purview Information Protection (Document-Level Encryption):

For Confidential-tier and Restricted-tier data (as defined in the Data Protection & Classification page), Microsoft Purview Information Protection applies an additional layer of document-level encryption through Sensitivity Labels:

• When a Sensitivity Label designating Confidential or Restricted is applied to a document or email, the content is encrypted using Microsoft Rights Management Service (Azure RMS) encryption.
• Encryption is persistent — it travels with the document regardless of where the file is copied, forwarded, or stored. A Restricted-labeled document remains encrypted even if it is downloaded to a personal device, attached to an external email, or uploaded to a third-party service.
• Access is controlled by the rights assigned in the Sensitivity Label. Unauthorized recipients cannot decrypt the content even if they obtain the file.
• Encryption keys for Purview-protected content are managed within the Azure Rights Management Service infrastructure.
  ‍

Encryption in Transit

All data transmitted to, from, and within the Ariana Nexus environment is encrypted in transit. Encryption in transit protects data against interception, eavesdropping, and man-in-the-middle attacks.

TLS (Transport Layer Security):

• All connections to Microsoft 365 services are secured with TLS 1.2 or higher. TLS 1.0 and TLS 1.1 are disabled and not supported.
• Ariana Nexus's website (ariananexus.com) is served over HTTPS with TLS 1.2+ enforced through Cloudflare. HTTP connections are automatically redirected to HTTPS.
• Internal service-to-service communication within the Microsoft 365 platform uses TLS encryption.

Email Encryption:

Ariana Nexus implements multiple layers of email encryption:

• Transport-Level Encryption (TLS): All email sent and received through Exchange Online is encrypted in transit using opportunistic TLS. When the recipient's mail server supports TLS, email is encrypted during transmission. Microsoft 365 enforces TLS 1.2 for all connections.
• Office Message Encryption (OME): Ariana Nexus uses Microsoft Office Message Encryption to send encrypted email messages to external recipients, regardless of whether the recipient uses Microsoft 365. OME-encrypted messages can be read by recipients using the OME portal, Outlook, or other supported clients. This is used for sending Confidential and Restricted content to external parties who require encryption.
• Purview Sensitivity Label Encryption: When an email is composed with a Confidential or Restricted Sensitivity Label applied, the message and its attachments are automatically encrypted using Azure RMS. Only authorized recipients specified in the label policy can decrypt and read the content.
• S/MIME (Roadmap): Ariana Nexus is evaluating Secure/Multipurpose Internet Mail Extensions (S/MIME) for certificate-based email encryption and digital signing for high-security communications, particularly for government and defense engagements requiring enhanced authentication of email origin. Target evaluation: 2027.

VPN and Remote Access:

• Remote access to any Ariana Nexus resources is secured through Microsoft Entra ID authentication with MFA and Conditional Access — not through traditional VPN. This approach is consistent with the Zero Trust principle that network location does not confer trust.
• Where VPN is required for specific client engagements or government compliance requirements, Ariana Nexus will deploy a compliant VPN solution with AES-256 encryption. Target: as required by engagement.

Encryption in Use (Planned)

Encryption in use — protecting data while it is being actively processed in memory — is an emerging capability that Ariana Nexus monitors and plans to adopt as the technology matures:

• Microsoft Azure Confidential Computing (Roadmap): Hardware-based Trusted Execution Environments (TEEs) that encrypt data in memory during processing. Relevant for future AI Data Factory workloads and sensitive government processing. Target evaluation: 2028, aligned with platform maturity and E5/Azure migration planning.
• Double Key Encryption (Roadmap): Microsoft Purview Double Key Encryption, which adds a customer-controlled encryption layer on top of Microsoft-managed encryption, ensuring that Microsoft cannot access the content. Relevant for engagements requiring sovereignty-grade protection. Target evaluation: 2027–2028.
  ‍

Key Management

‍

Current Model: Microsoft-Managed Keys

Ariana Nexus currently uses Microsoft-managed encryption keys for all Microsoft 365 service encryption and Azure Rights Management Service encryption. Under this model:

• Microsoft generates, stores, and manages all encryption keys within its FIPS 140-2 Level 2 validated (and Level 3 for certain modules) Hardware Security Modules (HSMs).
• Keys are rotated automatically by Microsoft in accordance with Microsoft's key management policies.
• Ariana Nexus does not have direct access to the encryption keys but retains full control over the data through access policies, Sensitivity Labels, and administrative controls.
• Microsoft's key management infrastructure is audited as part of Microsoft's SOC 2 Type II, ISO 27001, and FedRAMP certifications, and audit reports are available through the Microsoft Service Trust Portal.

Why This Model Is Appropriate Today:

For an organization at Ariana Nexus's current scale operating within Microsoft 365 Business Premium, Microsoft-managed keys provide enterprise-grade encryption with the operational simplicity and reliability of Microsoft's global infrastructure. The keys are managed within FIPS-validated HSMs, rotated automatically, and governed by Microsoft's extensively audited security program. This model satisfies the encryption requirements of HIPAA, NIST SP 800-171, GDPR, and CCPA.

Roadmap: Customer-Managed Keys (CMK)

As Ariana Nexus matures and the complexity of its engagements grows — particularly in government, defense, and sovereignty-sensitive contexts — the organization will transition to a customer-managed key model:

Phase 1 — Evaluation (2027): Evaluate Microsoft 365 Customer Key, which allows Ariana Nexus to provide and control root encryption keys for Microsoft 365 data at rest using keys stored in Azure Key Vault. Evaluate Azure Key Vault HSM-backed key storage for managing encryption keys within Ariana Nexus's own Azure tenant. Assess requirements for government engagements that mandate customer-controlled encryption (e.g., CMMC, FedRAMP, ITAR).

Phase 2 — Deployment (2027–2028): Deploy Microsoft 365 Customer Key for Exchange Online, SharePoint Online, and Teams, giving Ariana Nexus control over the root encryption keys for all data at rest. Deploy Azure Key Vault with HSM protection for managing application-level encryption keys. Implement key rotation policies and key access audit logging within Ariana Nexus's own infrastructure.

Phase 3 — Advanced Key Sovereignty (2028–2030): Deploy Double Key Encryption for the highest-sensitivity engagements, adding a customer-controlled key layer that prevents even Microsoft from accessing the data. Evaluate Hold Your Own Key (HYOK) models for engagements requiring that encryption keys never leave Ariana Nexus's physical or logical control. Implement key management procedures compliant with NIST SP 800-57 (Recommendation for Key Management).

Phase 4 — Post-Quantum Readiness (2030+): Monitor NIST Post-Quantum Cryptography (PQC) standardization and migration timelines. Develop a cryptographic agility plan to transition from current encryption algorithms (AES, RSA, ECC) to quantum-resistant algorithms as standards are finalized and platform support becomes available. This aligns with Ariana Nexus's multi-decade operational horizon through 2080, ensuring that data encrypted today remains secure against future quantum computing threats.

‍

Encryption Standards Reference

‍

Data at rest (M365 services) — AES-256, 256-bit. Microsoft service encryption, per-file and per-database.

Data at rest (Windows devices) — AES-256 (BitLocker), 256-bit. Enforced via Intune compliance policy.

Data at rest (macOS devices) — XTS-AES-128 (FileVault), 128-bit. Enforced via Intune compliance policy.

Data at rest (iOS devices) — AES-256 (hardware), 256-bit. Device-level, hardware-backed.

Data at rest (Android devices) — AES-256 (device encryption), 256-bit. Enforced via Intune compliance policy.

Document-level encryption — AES-256 (Azure RMS), 256-bit. Purview Sensitivity Labels (Confidential, Restricted).

Data in transit (web) — TLS 1.2+, 256-bit session keys. HTTPS enforced for ariananexus.com and all M365 services.

Data in transit (email) — TLS 1.2+, 256-bit session keys. Opportunistic TLS for all Exchange Online connections.

Email content encryption — AES-256 (OME / Azure RMS), 256-bit. Office Message Encryption and Sensitivity Label encryption.

Key storage (current) — FIPS 140-2 Level 2/3 HSMs. Microsoft-managed HSM infrastructure.

Key storage (roadmap) — Azure Key Vault HSM, configurable. Customer-managed keys, target 2027–2028.

‍

Alignment with Security and Compliance Frameworks

‍

Ariana Nexus's encryption and key management architecture is designed in alignment with the following recognized frameworks and standards:

HIPAA Security Rule (45 CFR § 164.312(a)(2)(iv), § 164.312(e)(1)) — Encryption of ePHI at rest and in transit. Aligned — AES-256 at rest, TLS 1.2+ in transit, Purview encryption for PHI documents.

NIST SP 800-171 Rev. 2 / Rev. 3 — SC-13 (Cryptographic Protection), SC-8 (Transmission Confidentiality). Aligned — FIPS-validated encryption for data at rest and in transit (Rev. 2 current for DoD/CMMC; Rev. 3 transition planned per DoD rulemaking).

NIST SP 800-57 — Key management lifecycle (generation, distribution, storage, rotation, destruction). Roadmap — currently Microsoft-managed; CMK with NIST 800-57 compliance planned (2027–2028).

CMMC Level 2 — System and Communications Protection (SC) domain. Roadmap (2027) — encryption controls implemented, CMK planned for certification.

GDPR (Article 32) — Encryption as appropriate technical measure for security of processing. Aligned — encryption at rest, in transit, and at document level.

UK GDPR — Same as GDPR. Aligned.

FIPS 140-2 / 140-3 — Cryptographic module validation. Aligned — Microsoft infrastructure uses FIPS 140-2 Level 2/3 validated HSMs.

PCI DSS (if applicable) — Encryption of cardholder data. Not currently applicable — Ariana Nexus does not process payment card data on its systems.

NIST PQC Standards — Post-quantum cryptographic algorithms. Roadmap (2030+) — monitoring NIST PQC standardization, cryptographic agility planning.

SOC 2 (Trust Services Criteria) — CC6.1 — Encryption of data at rest and in transit. Roadmap (2026–2027) — controls operational, audit planned.

ISO 27001:2022 — Annex A.8.24 — Use of Cryptography. Roadmap (2027) — controls aligned, certification planned.

EU AI Act — Data protection measures for AI training data. Aligned — Restricted-tier encryption for AI data containing PII.

‍

Sector-Specific Encryption Applications

Healthcare (HIPAA)

Protected Health Information is encrypted at every layer: at rest in SharePoint via Microsoft service encryption (AES-256), in transit via TLS 1.2+, at the document level via Purview Sensitivity Labels (Restricted tier, Azure RMS encryption), on endpoints via BitLocker/FileVault, and in email via OME or Sensitivity Label encryption. Encryption satisfies the HIPAA Security Rule addressable implementation specification for encryption of ePHI at rest (45 CFR § 164.312(a)(2)(iv)) and the standard for transmission security (45 CFR § 164.312(e)(1)).

Government (CUI / NIST 800-171)

Controlled Unclassified Information is encrypted using FIPS-validated cryptographic modules at rest and in transit, satisfying NIST SP 800-171 control SC-13 (Cryptographic Protection) and SC-8 (Transmission Confidentiality and Integrity). Customer-managed keys via Azure Key Vault are on the roadmap to provide Ariana Nexus-controlled key management for CUI environments, addressing government expectations for key sovereignty.

AI & Technology (AI Data Factory)

AI training data containing personally identifiable information is classified as Restricted and encrypted at the document level via Purview Sensitivity Labels. Data provenance records and annotation outputs inherit the encryption classification of the underlying dataset. Client-provided AI data is encrypted using the same standards, with additional encryption layers applied per the Data Processing Agreement where required.

Research & Education

Research data involving human subjects or sensitive academic data is encrypted based on its classification tier. Restricted-tier research data receives full document-level encryption with access limited to the approved research team.

‍

What Encryption Means for Our Clients and Partners

‍

For procurement officers: Every piece of data you entrust to Ariana Nexus is encrypted at rest (AES-256), in transit (TLS 1.2+), and at the document level (Azure RMS) for sensitive classifications. Encryption is not optional — it is the default state of all data in our environment. We can provide encryption configuration evidence and compliance mapping on request.

For CISOs: Our encryption architecture uses Microsoft's FIPS 140-2 Level 2/3 validated infrastructure with a defined path to customer-managed keys, giving you confidence in the cryptographic foundation today and key sovereignty in the future. Full-disk encryption is enforced on every device through Intune — no exceptions.

For compliance officers: Our encryption standards satisfy the cryptographic requirements of HIPAA, NIST SP 800-171, GDPR Article 32, and FIPS 140-2. Encryption key management is currently Microsoft-managed with full audit trail availability through the Microsoft Service Trust Portal. Our roadmap to customer-managed keys addresses the key sovereignty requirements of CMMC, FedRAMP, and advanced government engagements.

For government contracting officers: CUI encryption uses FIPS-validated modules. Customer-managed keys via Azure Key Vault are planned for 2027–2028, aligned with our CMMC Level 2 certification target. Post-quantum cryptographic migration is on our long-term roadmap, ensuring data encrypted today remains protected against future threats.

If your organization requires encryption architecture documentation, key management evidence, or a cryptographic compliance briefing, contact trust@ariananexus.com or +1 (202) 771-0224.

‍

Maturity Roadmap

Ariana Nexus views encryption and key management as a multi-year journey. The following roadmap reflects our planned maturation path:

Phase 1: Foundation (Current — 2026) — Operational

AES-256 at rest across all M365 services. TLS 1.2+ in transit. BitLocker/FileVault enforced on all devices. Purview Sensitivity Label encryption for Confidential and Restricted data. OME for encrypted external email. Microsoft-managed keys in FIPS 140-2 validated HSMs.

Phase 2: Hardening (2027) — In Planning

Customer Key evaluation and deployment (Azure Key Vault). S/MIME evaluation for certificate-based email encryption. SOC 2 Type II audit (CC6.1 encryption controls). NIST SP 800-57 key management alignment.

Phase 3: Certification (2027–2028) — Planned

Customer-managed keys deployed for M365 data at rest. Azure Key Vault HSM-backed key storage operational. CMMC Level 2 SC domain certification. ISO 27001 Annex A.8.24 certification.

Phase 4: Advanced (2028–2030) — Planned

Double Key Encryption for sovereignty-grade engagements. Hold Your Own Key evaluation. FedRAMP encryption requirements. Confidential computing evaluation for AI workloads.

Phase 5: Quantum-Ready (2030+) — Vision

Post-quantum cryptographic algorithm migration. Cryptographic agility framework. Quantum key distribution evaluation. Long-horizon data protection through 2080.

‍

Limitation of Liability and Disclaimers

‍

No Guarantee of Encryption Invulnerability. Ariana Nexus implements encryption using commercially recognized standards and FIPS-validated infrastructure. However, no encryption algorithm is guaranteed to be permanently invulnerable. Advances in computing technology, including quantum computing, may affect the long-term security of current encryption standards. Ariana Nexus monitors cryptographic developments and plans for algorithm migration as described in the roadmap, but does not warrant that currently encrypted data will remain secure against all future technological capabilities.

Microsoft-Managed Key Dependency. Ariana Nexus currently relies on Microsoft-managed encryption keys. While Microsoft's key management infrastructure is FIPS 140-2 validated and independently audited, Ariana Nexus does not control Microsoft's key management operations and disclaims liability for any incident attributable to Microsoft's key management infrastructure. Customer-managed keys are on the roadmap to provide Ariana Nexus with direct key control.

Roadmap Items. The maturity roadmap reflects current plans as of the Effective Date. Roadmap items, including customer-managed keys, Double Key Encryption, and post-quantum migration, are forward-looking statements and not binding commitments. Ariana Nexus reserves the right to modify roadmap items at its sole discretion.

Client-Specific Encryption Obligations. The encryption standards described on this page represent Ariana Nexus's general organizational posture. Specific encryption requirements for individual client engagements are defined in the applicable Engagement Agreement. Where a client requires encryption standards beyond those described herein, such requirements will be addressed through the engagement-specific Data Protection Plan.

Limitation of Liability. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, ARIANA NEXUS'S TOTAL AGGREGATE LIABILITY FOR ALL CLAIMS ARISING OUT OF OR RELATED TO ENCRYPTION AND KEY MANAGEMENT SHALL NOT EXCEED THE AMOUNTS SET FORTH IN THE APPLICABLE ENGAGEMENT AGREEMENT, OR, WHERE NO ENGAGEMENT AGREEMENT EXISTS, ONE HUNDRED DOLLARS ($100). ARIANA NEXUS SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES ARISING FROM OR RELATED TO ANY ENCRYPTION FAILURE, KEY COMPROMISE, OR CRYPTOGRAPHIC VULNERABILITY. NOTHING IN THIS SECTION SHALL LIMIT OR EXCLUDE ARIANA NEXUS'S LIABILITY FOR: (A) FRAUD OR FRAUDULENT MISREPRESENTATION; (B) DEATH OR PERSONAL INJURY CAUSED BY NEGLIGENCE; OR (C) ANY OTHER LIABILITY THAT CANNOT BE EXCLUDED OR LIMITED BY APPLICABLE LAW, INCLUDING BUT NOT LIMITED TO LIABILITY UNDER THE UK UNFAIR CONTRACT TERMS ACT 1977, THE UK CONSUMER RIGHTS ACT 2015, OR GDPR.

‍

Dispute Resolution. Any dispute arising out of or relating to this page shall be subject to the dispute resolution provisions in the Terms of Use, Section 18.