Using Azure Key Vault HSM for High-Sensitivity Data (2-8-3)

ECC 2-8-3 requires the organization to apply approved cryptographic standards, manage keys securely throughout their lifecycle, and encrypt classified data in transit, at rest, and where required while processing. An Azure Key Vault Managed HSM configuration can satisfy the key-generation, storage, access-control, rotation, deletion-protection, and audit-evidence portions of the control when it is paired with an approved cryptography standard, workload encryption settings, and controls for TLS and confidential processing.

What does ECC 2-8-3 require from the organization?

Essential Cybersecurity Controls 2:2024 practice 2-8-3 is not simply a requirement to buy an HSM. It requires a documented and approved cryptography standard that selects appropriate controls from the National Cryptographic Standards published by NCA, based on data classification, risk assessment, systems, networks, and applicable legal obligations.

For a COO or finance owner, the investment decision is therefore broader than the Azure service cost. The organization needs a controlled service for high-sensitivity keys, defined ownership, protected administration, lifecycle procedures, evidence collection, and technical enforcement in the systems that actually store or transmit sensitive data.

How do you complete an Azure Key Vault Managed HSM configuration?

The following configuration establishes a defensible baseline for high-sensitivity encryption keys. Before technical staff begin, the approved cryptography standard should state which data classifications require HSM-backed customer-managed keys, the approved cryptographic algorithms and key lengths, and the maximum permitted key lifetime.

1. Create a dedicated Managed HSM resource. In the Azure portal, search for Managed HSM, select Create, and complete the Basics tab. Select the production subscription, a dedicated resource group such as rg-crypto-prod, a supported region, and a meaningful name such as mhsm-finance-prod-01.

   Assign only the designated break-glass cryptography administrator during creation. Do not use a general infrastructure administrator or a shared account. Record the subscription, region, service owner, and business owner in the cryptography asset register.

2. Protect the security domain. After deployment, open the Managed HSM resource and select Security domain > Download security domain. Configure a quorum of at least three security-domain administrators, with a threshold such as two of three required to recover the security domain.

   The downloaded security-domain package is a recovery asset, not an ordinary backup file. Store each administrator certificate and recovery package under the approved recovery procedure, with separate custodians and documented access. A finance executive should require evidence that no single employee can reconstruct the environment alone.

3. Restrict network access. Open Managed HSM > Networking. Set Public network access to Disabled, then select Private endpoint connections > Create. Place the private endpoint in the approved production virtual network and subnet.

   Confirm that private DNS resolution is configured for the Managed HSM private endpoint. This prevents workload teams from bypassing the approved network path by reaching the service from public networks.

4. Assign separated key-management roles. Open Managed HSM > Access control (IAM) > Add > Add role assignment. Assign roles to Entra ID groups and managed identities, not named daily-use administrator accounts.

   • Managed HSM Administrator: restricted break-glass administration only.
   • Managed HSM Crypto Officer: designated cryptography team members who create, rotate, disable, and retire keys.
   • Managed HSM Crypto User: application managed identities that perform permitted cryptographic operations.
   • Managed HSM Crypto Service Encryption User: managed identities used by supported Azure services for customer-managed encryption.

   Separate the person who approves a key request from the person who can create or rotate the key. This supports both key lifecycle governance and finance-grade segregation of duties.

5. Create an HSM-backed encryption key with an approved lifecycle. Open Managed HSM > Keys > Generate/Import > Generate. Use a controlled naming convention such as cmk-finance-records-prod. Select RSA-HSM and select the key size approved in the organization’s cryptography standard, for example 3072 bits where that is the approved requirement.

   Set Activation date, Expiration date, and keep Enabled selected. Do not permit key export. Managed HSM keys are designed to remain protected by the HSM boundary rather than being downloaded into application servers.

6. Set the rotation policy. Open the new key, select Rotation policy, and select Set rotation policy. A realistic baseline for a high-sensitivity production encryption key is automatic rotation after 365 days, expiration after 730 days, and notification 30 days before expiry.

   The exact values must come from the approved key lifecycle procedure and risk assessment. The important compliance outcome is that the policy is set on the key, key versions are traceable, and the service owner receives time to test dependent applications before a key expires.

7. Connect the protected workload to the key. For Azure Storage, open Storage accounts > select the production storage account > Encryption. Under Encryption key, select Customer-managed keys, then select the Managed HSM instance and key. Enable the storage account managed identity under Identity before granting it the required Managed HSM crypto service encryption role.

   For Azure SQL workloads, enable the SQL server’s managed identity at SQL servers > select server > Identity, grant that identity the appropriate Managed HSM encryption role, then configure the customer-managed Transparent Data Encryption protector through the SQL server’s Transparent data encryption settings.

For example, a hypothetical semi-government entity, Eastern Civic Finance Authority, with 1,250 employees could use this design to protect customer-managed keys for its payment-record archive and finance document repository. Its finance system team requests a key through a service ticket, the cryptography officer creates the key in Managed HSM, and the platform team applies it to the production storage account; no application developer receives the private key material.

How do you verify that the settings took effect?

Technical staff should verify the configuration after deployment and again after every material change. A managed HSM deployment that exists but is reachable publicly, administered by excessive users, or not connected to the intended workload does not meet the practical intent of ECC 2-8-3.

1. Open Managed HSM > Overview and confirm the correct resource name, subscription, region, and provisioning state.
2. Open Networking and confirm Public network access: Disabled and that the approved private endpoint shows Approved.
3. Open Properties and confirm soft delete and purge protection are enabled. Managed HSM is designed to prevent immediate irreversible deletion, but the retention period must align with the approved procedure.
4. Open Access control (IAM) > Role assignments and confirm only approved Entra ID groups and managed identities hold Managed HSM roles.
5. Open Keys > select the key and confirm Key type: RSA-HSM, the approved key size, enabled status, expiry date, and the configured Rotation policy.
6. Open the dependent storage account or SQL server and confirm that Customer-managed keys or the customer-managed TDE protector is selected and points to the intended HSM key.
7. Open Monitoring > Activity log on the Managed HSM resource and confirm key creation, role-assignment, networking, and configuration events are recorded.

What evidence should be captured for an ECC 2-8-3 assessor?

Capture evidence at implementation and preserve it in the control evidence repository, not only in a project ticket. Screenshots should include the Azure portal breadcrumb, resource name, date, and relevant setting; exports should be retained in their original format.

• The approved cryptography standard controls document, including approved algorithms, key lifecycle rules, PKI restrictions, TLS requirements, and data-classification decisions.
• Formal approval by the head of the organization or delegated authority, using the approved signature or official email process.
• A screenshot of Networking showing disabled public network access and approved private endpoint connections.
• A screenshot or export of Access control (IAM) role assignments, demonstrating separation between administrators, crypto officers, and workload identities.
• A screenshot of each relevant key showing RSA-HSM, key size, activation and expiry dates, enabled status, and rotation policy.
• A screenshot from each protected workload showing customer-managed encryption enabled and the Managed HSM key selected.
• Activity Log exports showing key creation, rotation, role changes, and deletion-related events.
• The key-management procedure, quarterly access review record, and documented annual effectiveness review of key lifecycle controls.

Where does Azure Managed HSM fall short, and what fills the gap?

Managed HSM is a key-management and cryptographic-operation service; it does not independently encrypt every dataset, enforce TLS for every application, classify data, or encrypt data while applications process it in memory. Treating the HSM as a complete answer to ECC 2-8-3 would leave material gaps.

For data in transit, require TLS through the application, API gateway, Azure Application Gateway, Azure Front Door, or equivalent service, using the protocol and cipher requirements approved in the organization’s cryptography standard. For data at rest, enable customer-managed keys only on supported services and validate the integration after each key rotation. For data while processing, use Azure confidential computing capabilities, such as confidential virtual machines or confidential containers, where the risk assessment and legal requirements call for protection of data in use.

A second example is a 600-person government-owned utilities company using Managed HSM for keys protecting billing archives and smart-meter settlement exports. The HSM protects encryption keys and signing keys, while TLS is enforced at its API gateway and confidential compute is evaluated separately for analytics workloads that process sensitive consumer data.

Next step: ask the technical owner for a costed design that maps each high-sensitivity workload, its classification, its HSM key, its encryption method, and its ECC 2-8-3 evidence owner before approving implementation funding.