Share via

Data Protection

Data protection safeguards sensitive information from unauthorized access, exfiltration, and misuse across the complete data lifecycle. Implement discovery and classification to establish data inventory, encryption to protect data in transit and at rest, and disciplined key and certificate management to maintain cryptographic integrity. This layered approach aligns with Zero Trust principles and defense-in-depth strategies.

Without comprehensive data protection, organizations face data breaches, regulatory penalties, and reputational damage from exfiltration of sensitive information.

Here are the three core pillars of the Data Protection security domain.

Know and classify your data: Discover sensitive information and apply consistent labels to enable risk-based controls.

Related controls:

Protect data with encryption: Implement comprehensive encryption for data in transit and at rest using modern cryptographic standards.

Related controls:

Manage cryptographic infrastructure: Establish disciplined lifecycle management for cryptographic keys and certificates with automated rotation and comprehensive audit logging.

Related controls:

DP-1: Discover, classify, and label sensitive data

Azure Policy: See Azure built-in policy definitions: DP-1.

Security principle

Establish and maintain a comprehensive inventory of sensitive data by discovering, classifying, and labeling data across all repositories. This enables risk-based access controls, encryption policies, and monitoring to protect against unauthorized access and exfiltration.

Risk to mitigate

Threat actors exploit lack of visibility and inconsistent handling of sensitive data to exfiltrate or abuse high-value information. When sensitive data isn't discovered, classified, or labeled:

  • Untracked regulated data: (PCI, PHI, PII) stored in unmanaged locations (shadow IT) bypasses required encryption, retention, or monitoring controls.
  • Over-privileged access: Broad user/service access persists because sensitivity and business impact aren't identified.
  • Replica proliferation: Data replication to analytics, test, or export pipelines spreads sensitive content into lower-trust environments.
  • Forensic blind spots: Incident responders cannot rapidly scope blast radius due to absent or incorrect sensitivity metadata.
  • Automation failure: Governance (DLP, conditional access, encryption workflows) fails to trigger without consistent labeling.

Lack of foundational classification increases dwell time, widens lateral movement opportunities, and elevates regulatory and reputational exposure.

MITRE ATT&CK

  • Reconnaissance (TA0043): gathering victim identity / data assets (T1596) by enumerating storage accounts, schema catalogs, and classification metadata to profile high-value repositories.
  • Discovery (TA0007): account & permission enumeration (T1087, T1069) to reveal excessive role bindings enabling horizontal or vertical data access escalation.
  • Collection (TA0009): data from cloud storage (T1530) by extracting unlabeled blob containers or unmanaged exports lacking tracking tags.
  • Exfiltration (TA0010): exfiltration over web services (T1567) through ad-hoc export endpoints where labeling/policy gates are absent.
  • Exfiltration (TA0010): automated exfiltration (T1020) using scripted pagination / looping to quietly harvest misclassified data sets.

DP-1.1: Discover, classify, and label sensitive data

Use Microsoft Purview to build a comprehensive data map that automatically discovers, classifies, and labels sensitive information across your entire data estate. Extend protection beyond infrastructure-level encryption by implementing Microsoft Purview Information Protection to apply persistent document-level encryption and usage rights that follow data wherever it travels. This foundational capability enables downstream security controls such as data loss prevention, conditional access, and encryption policies to operate based on data sensitivity rather than location alone.

Data discovery and classification:

  • Deploy Microsoft Purview to discover, classify, and label sensitive data across Azure, on-premises, Microsoft 365, and multi-cloud environments.
  • Use Microsoft Purview Data Map to automatically scan and catalog data sources including Azure Storage, Azure SQL Database, Azure Synapse Analytics, and other supported services.
  • Enable sensitivity labels in Purview Data Map to automatically apply classification labels (e.g., Confidential, Highly Confidential, PII, PHI) based on data content patterns and organizational policies.

Document-level encryption and protection:

  • Deploy Microsoft Purview Information Protection to apply persistent encryption and usage rights to documents and emails based on sensitivity labels. Configure labels to automatically encrypt files, apply watermarks, restrict forwarding, set expiration dates, and revoke access even after data leaves your organization.
  • Enable Azure Rights Management Service (Azure RMS) as the underlying protection technology that encrypts documents and emails with usage policies (view-only, no-copy, no-print) that persist regardless of where data is stored or shared.

Database classification and integration:

  • For Azure SQL databases, enable SQL Data Discovery & Classification to identify, classify, and label columns containing sensitive data such as credit card numbers, social security numbers, or health records.
  • Integrate classification metadata with downstream controls: configure Data Loss Prevention (DLP) policies in Microsoft Purview, apply conditional access rules in Entra ID, and enforce encryption policies based on sensitivity labels.
  • Establish a regular scanning schedule to continuously discover newly created or modified sensitive data assets as your data estate evolves.

Implementation example

A global financial services organization deployed Microsoft Purview Data Map to automatically discover and classify sensitive data across 200+ Azure Storage accounts, 50 SQL databases, and Synapse Analytics workspaces.

Challenge: The organization lacked visibility into where sensitive data resided across their rapidly growing Azure data estate. Manual data classification was inconsistent, delayed governance enforcement, and created compliance gaps. Without automated discovery, regulated data (PHI, PII, PCI) remained unprotected in unmanaged locations, and data loss prevention policies couldn't trigger appropriately.

Solution approach:

  • Deploy Microsoft Purview Data Map for data discovery: Create a Purview account and register data sources (Azure Storage accounts, SQL databases, Synapse Analytics workspaces), configure Data Map to scan sources using managed identity authentication, grant scanning identity read permissions (db_datareader role) to catalog schemas and detect sensitive columns.
  • Configure classification and sensitivity detection: Set up scan rules to detect sensitive patterns (SSN, credit card numbers, medical record numbers, SWIFT codes), define custom classification rules aligned with data classification policy ("Confidential - Internal" for business-sensitive data, "Highly Confidential - Regulated" for PHI/PCI/PII data), configure automatic labeling thresholds (apply "Highly Confidential" when ≥3 PII patterns detected in single asset), establish scan schedules based on data criticality (weekly for production, monthly for archives), configure alerts to notify security teams when new high-sensitivity data is discovered.
  • Deploy Microsoft Purview Information Protection for document-level encryption: Create sensitivity labels in Purview compliance portal with protection settings (Public: no encryption, visual markings only; Internal: watermark, no forwarding restrictions; Confidential: encrypt with Azure RMS, allow view/edit for employees only, block forwarding/printing; Highly Confidential - Regulated: encrypt with Azure RMS, view-only access, no copy/print/forward, 90-day expiration, revocable access), publish sensitivity labels to users via label policies (scope: Finance, Legal, Executive departments), configure auto-labeling policies to automatically apply labels (≥10 SSNs → "Highly Confidential - Regulated", ≥5 credit card numbers → "Highly Confidential - Regulated"), enable Azure RMS protection for labeled documents stored in SharePoint, OneDrive, and Azure Storage accounts, configure client-side labeling for Office applications to prompt users to classify documents before saving/sending.

Outcome: Purview Data Map auto-scanning identified over 15,000 data assets containing regulated data within the first week, reducing discovery time from months to days. Information Protection auto-labeling applied encryption to 8,500 documents within 72 hours. Sensitivity labels enabled continuous data estate visibility and persistent protection even when data moves to unmanaged devices.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: 3.2, 3.7, 3.13
  • NIST SP 800-53 Rev.5: RA-2, SC-28
  • PCI-DSS v4: 3.2.1, 12.3.1
  • NIST CSF v2.0: PR.DS-1, PR.DS-5
  • ISO 27001:2022: A.8.11
  • SOC 2: CC6.1

DP-2: Monitor anomalies and threats targeting sensitive data

Azure Policy: See Azure built-in policy definitions: DP-2.

Security principle

Monitor sensitive data access and transfer activities for anomalies that indicate unauthorized exfiltration, insider threats, or compromised accounts. Use behavioral baselines and data sensitivity context to detect unusual patterns such as large transfers, abnormal access times, or unexpected data movement.

Risk to mitigate

Adversaries and malicious insiders attempt to exfiltrate, stage, or probe sensitive data using stealthy or low-signal behaviors. Without continuous, context-aware anomaly monitoring tied to data sensitivity:

  • Silent exfiltration: Bulk exports, large result sets, or incremental siphoning proceed undetected due to lack of baselines.
  • Insider misuse: Legitimate credentials perform unusual sequences (time-of-day, volume, locality) that bypass coarse monitoring.
  • Staging & enumeration: Attackers map schemas / labels to prioritize high-value targets before mass extraction.
  • Living-off-the-land queries: Standard administrative tools mask reconnaissance in normal operational noise.
  • Cross-store evasion: Distributed access across multiple services avoids single-store thresholds and correlation.

Inadequate anomaly detection erodes incident response efficacy and allows escalation from reconnaissance to full-scale exfiltration with minimal friction.

MITRE ATT&CK

  • Collection (TA0009): data from cloud storage (T1530) via anomalous bulk or wide fan-out reads across sensitive containers.
  • Credential Access (TA0006): valid accounts (T1078) abusing compromised or insider credentials to blend with legitimate traffic baselines.
  • Exfiltration (TA0010): automated exfiltration (T1020) using scripted, throttled queries engineered to avoid alert thresholds.
  • Exfiltration (TA0010): exfiltration to cloud storage (T1567.002) staging data in attacker-controlled regions or accounts for later retrieval.
  • Command & Control / Exfiltration (TA0011/TA0010): application layer protocol (T1071) tunneling sensitive rows via normal DB/API calls.
  • Discovery (TA0007): system / service discovery (T1082, T1046) enumerating endpoints to chart lateral movement paths to higher-value stores.

DP-2.1: Enable threat detection for data services

Deploy Microsoft Defender services to provide real-time threat detection and anomaly monitoring across your data storage and database platforms. These services use behavioral analytics and threat intelligence to identify suspicious activities such as SQL injection attempts, anomalous query patterns, unusual data access volumes, and potential exfiltration indicators that traditional access controls cannot detect.

Enable threat detection for data services:

  • Enable Microsoft Defender for Storage with malware scanning and sensitive data threat detection to monitor anomalous access patterns, unusual upload/download volumes, and potential data exfiltration attempts across Azure Storage accounts.
  • Enable Microsoft Defender for SQL to detect suspicious database activities including SQL injection attempts, anomalous query patterns, unusual data export operations, and access from unfamiliar locations.
  • Enable Microsoft Defender for Azure Cosmos DB to detect anomalous database access patterns, potential data exfiltration, and suspicious operational activities.
  • For open-source databases (PostgreSQL, MySQL, MariaDB), enable Microsoft Defender for open-source relational databases to detect brute-force attacks, suspicious access patterns, and anomalous administrative operations.

DP-2.2: Monitor and prevent data exfiltration

Implement proactive data loss prevention controls and behavioral monitoring to detect and block unauthorized data transfers before they succeed. Combine policy-based DLP with insider risk management, SIEM correlation, and automated response to create a defense-in-depth approach that stops exfiltration attempts across multiple channels while providing forensic evidence for incident investigation.

Deploy DLP and insider risk controls:

  • Use Microsoft Purview Data Loss Prevention (DLP) policies to prevent sensitive data exfiltration by monitoring and blocking unauthorized transfers of classified data across Azure services, Microsoft 365, and endpoints.
  • Deploy Microsoft Purview Insider Risk Management to detect risky user behaviors using machine learning and behavioral analytics. Monitor indicators including unusual data downloads, copying files to USB/personal cloud storage, accessing sensitive resources outside normal working hours, or data access spikes before resignation dates. Insider Risk Management correlates signals from Microsoft 365, Azure, HR systems, and security tools to identify potential data theft or policy violations.

Configure monitoring and response:

  • Configure diagnostic logs for data services and route them to Azure Monitor or Microsoft Sentinel to establish behavioral baselines and detect deviations from normal access patterns.
  • Integrate data service logs with Microsoft Sentinel to create analytics rules for detecting anomalous data access patterns such as bulk downloads, off-hours access, or suspicious query behaviors.
  • Implement automated incident response workflows using Azure Logic Apps or Microsoft Sentinel playbooks to isolate compromised identities, revoke access, and notify security teams when data exfiltration attempts are detected.

Note: For host-based DLP requirements, deploy Microsoft Purview Endpoint DLP capabilities or third-party solutions from Azure Marketplace to enforce endpoint-level data protection controls.

Implementation example

A healthcare provider enabled Microsoft Defender for Storage and Defender for SQL to monitor anomalies and threats targeting patient data across Azure Storage accounts and SQL databases.

Challenge: The organization experienced blind spots in detecting unauthorized data access and exfiltration attempts. Traditional perimeter defenses missed insider threats and compromised service principals performing bulk downloads. Without behavioral analytics and anomaly detection, suspicious access patterns went unnoticed for extended periods, increasing breach risk and dwell time.

Solution approach:

  • Enable Microsoft Defender for Storage: Enable Defender for Storage at subscription level for storage accounts containing sensitive data, configure malware scanning to detect and quarantine malicious files in blob storage, enable sensitive data threat detection using Purview Sensitive Information Types to identify PHI/PII patterns, set per-transaction scanning limits or monthly caps to control costs, apply protection to resource groups containing production Storage accounts hosting medical imaging and EHR exports.
  • Enable Microsoft Defender for SQL: Enable Defender for SQL at subscription level for Azure SQL Database and SQL Managed Instance, configure Vulnerability Assessment with recurring scans and designate storage account for scan results, set up email notifications to alert security team of identified vulnerabilities, enable Advanced Threat Protection to detect SQL injection attempts, unusual query patterns, anomalous access from unfamiliar regions, and potential data exfiltration.
  • Integrate with Microsoft Sentinel: Connect Microsoft Defender for Cloud to Microsoft Sentinel using data connector, configure diagnostic settings (enable diagnostic logs for storage operations and SQL auditing logs, route to Log Analytics workspace), create Sentinel Analytics rules to detect anomalies (bulk download alerts for downloads >10 GB within 1 hour, off-hours database access, suspicious query patterns), configure automated response playbooks to isolate compromised identities, revoke storage access, and notify security teams.
  • Deploy Microsoft Purview Insider Risk Management for behavioral threat detection: Enable Insider Risk Management and configure policy templates (data theft by departing users detecting unusual file downloads 30-90 days before resignation, general data leaks monitoring USB/cloud storage copying, data leaks by priority users with enhanced monitoring for high-privilege roles), configure risk indicators and thresholds (cumulative file download volume alerts, off-hours access spikes, sequence detection combining multiple risky signals), integrate data sources (Azure Activity Logs, Microsoft 365 audit logs, Defender for Cloud Apps, HR systems, endpoint DLP events), configure alert triage workflow routing medium/high-severity alerts to dedicated investigation queue.

Outcome: Defender for Storage detected anomalous bulk download activity from a compromised service principal within 48 hours. Automated response isolated the identity and notified the SOC within minutes, reducing detection time from days to under 15 minutes. Insider Risk Management flagged a departing employee downloading research data significantly above personal baseline to personal cloud storage, enabling rapid intervention.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: 3.13
  • NIST SP 800-53 Rev.5: AC-4, SI-4
  • PCI-DSS v4: 3.2.1, 10.4.1
  • NIST CSF v2.0: DE.CM-1, PR.DS-5
  • ISO 27001:2022: A.8.11, A.8.16
  • SOC 2: CC6.1, CC7.2

DP-3: Encrypt sensitive data in transit

Azure Policy: See Azure built-in policy definitions: DP-3.

Security principle

Protect data in transit using strong encryption (such as TLS 1.2 or later) to prevent interception, tampering, and unauthorized access. Define network boundaries and service scopes where encryption is mandatory, prioritizing external and public network traffic while considering internal network protection based on data sensitivity.

Risk to mitigate

Unencrypted or weakly protected network channels expose sensitive data to interception, manipulation, and downgrade abuse. Absent enforced modern transport encryption (TLS 1.2+):

  • Passive interception: Network observers capture credentials, tokens, API payloads, or regulated data in plaintext.
  • Man-in-the-middle: Attackers alter queries, inject payloads, or harvest session material.
  • Protocol downgrade: Legacy fallback (SSL/TLS < 1.2, plaintext HTTP/FTP) enables exploitation of deprecated cipher suites.
  • Session hijacking: Lack of channel integrity allows token replay or cookie theft for lateral movement.
  • Integrity manipulation: Tampering corrupts analytics or triggers fraudulent transactions.
  • Opaque lateral paths: Internal plaintext traffic becomes reconnaissance material post foothold.

Failure to enforce strong encryption in transit amplifies breach blast radius, accelerates credential compromise, and undermines zero trust assumptions.

MITRE ATT&CK

  • Credential Access (TA0006): unprotected credentials (T1552) intercepted during plaintext or downgraded TLS sessions exposing tokens/session material.
  • Collection (TA0009): network sniffing (T1040) harvesting API payloads and secrets traversing weak cipher or cleartext paths.
  • Exfiltration (TA0010): exfiltration over web services (T1567) streaming structured data through legitimate API endpoints.
  • Defense Evasion (TA0005): adversary-in-the-middle (T1557) forcing TLS downgrade or inserting interception proxies to view/modify traffic.
  • Command & Control (TA0011): non-application layer protocol (T1095) reverting to legacy or less-inspected transports to bypass monitoring.

DP-3.1: Enforce TLS encryption for data services and applications

Establish modern transport layer security standards across all customer-facing services and data platforms to protect against interception, tampering, and man-in-the-middle attacks. Enforce minimum TLS 1.2 or 1.3 across storage, web applications, databases, and API gateways while disabling legacy protocols and weak cipher suites that expose data to cryptographic downgrade attacks.

Enforce TLS for data services and applications:

  • Enforce secure transfer (HTTPS only) for Azure Storage accounts to ensure all client connections use TLS 1.2 or later for blob, file, queue, and table operations.
  • For web applications hosted on Azure App Service, enable "HTTPS Only" setting and configure minimum TLS version to 1.2 or 1.3 to prevent downgrade attacks and ensure modern cryptographic standards.
  • Configure Azure Application Gateway to enforce TLS 1.2/1.3 minimum version for both frontend listeners and backend connection encryption (end-to-end TLS).
  • For Azure SQL Database and other PaaS data services, verify that "Require Secure Connections" or equivalent settings enforce encrypted connections; reject plaintext connections.
  • For API Management, Azure Front Door, and other gateway services, configure minimum TLS version policies to enforce TLS 1.2 or higher and disable weak cipher suites.

Note: Azure automatically encrypts all traffic between Azure datacenters using MACsec (layer 2) and TLS (layer 7). Most Azure PaaS services enable TLS 1.2+ by default, but verify minimum TLS version settings for services with customer-configurable policies (Storage, App Service, Application Gateway, API Management, Front Door).

DP-3.2: Secure remote access and file transfer protocols

Eliminate plaintext administrative access and legacy file transfer protocols that expose credentials and sensitive data during operational activities. Replace insecure protocols (FTP, unencrypted RDP/SSH) with modern, encrypted alternatives and route privileged access through centralized bastions to eliminate direct internet exposure of management interfaces.

Secure remote management protocols:

  • For remote management of Azure virtual machines, use secure protocols exclusively:
    • Linux VMs: Use SSH (port 22) with key-based authentication; disable password authentication.
    • Windows VMs: Use RDP over TLS (port 3389) with Network Level Authentication (NLA) enabled.
    • Privileged access: Route administrative connections through Azure Bastion to eliminate public IP exposure and provide browser-based or native client access over TLS.

Secure file transfer protocols:

  • For file transfer operations, use secure protocols and disable legacy alternatives:
  • Use Azure Policy to enforce secure transfer policies across your environment and monitor compliance for TLS version requirements.

Implementation example

An e-commerce platform enforced TLS 1.3 minimum version across all customer-facing services to meet PCI-DSS 4.0 requirements.

Challenge: Legacy TLS 1.0/1.1 protocols and weak cipher suites exposed customer payment data to interception attacks. Inconsistent TLS enforcement across application tiers created security gaps where attackers could downgrade connections. Without centralized TLS policy enforcement, manual configuration drift allowed insecure protocols to persist in production.

Solution approach:

  • Configure Azure App Service for TLS 1.3: Set minimum TLS version to 1.3 for customer-facing web applications and APIs, enable HTTPS-only mode to automatically redirect all HTTP traffic to HTTPS, verify that managed certificates or custom certificates use strong cipher suites.
  • Configure Azure Application Gateway for end-to-end TLS: Configure frontend HTTPS listener with SSL policy AppGwSslPolicy20220101 (TLS 1.3 minimum with CustomV2 policy), upload TLS certificate or integrate with Key Vault for certificate management, configure backend settings for HTTPS connections (set backend protocol to HTTPS on port 443, enable "Use well known CA certificate" if backend App Services use Azure-managed certificates, set minimum TLS version to 1.2 for backend connections), create routing rules linking HTTPS listeners to backend pools with TLS-enabled settings.
  • Enforce secure transfer for Azure Storage: Enable "Secure transfer required" setting to enforce HTTPS-only for blob, file, queue, and table operations, set minimum TLS version to 1.2 for all storage connections, verify that all SAS tokens and shared keys only work over HTTPS connections.
  • Configure Azure Bastion for secure remote access: Deploy Azure Bastion in hub VNet to provide browser-based RDP/SSH access over TLS 1.2, remove public IPs from VMs and route all administrative access exclusively through Bastion.

Outcome: Azure Storage accounts reject HTTP connections at the service boundary, Application Gateway enforces TLS 1.3 for frontend connections with TLS 1.2 backend encryption, and Azure Bastion eliminates public IP exposure for VM management.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: 3.10
  • NIST SP 800-53 Rev.5: SC-8
  • PCI-DSS v4: 4.2.1, 4.2.2
  • NIST CSF v2.0: PR.DS-2
  • ISO 27001:2022: A.8.24
  • SOC 2: CC6.1, CC6.7

DP-4: Enable data at rest encryption by default

Azure Policy: See Azure built-in policy definitions: DP-4.

Security principle

Enable encryption at rest by default to protect data against unauthorized access through underlying storage, physical media theft, snapshot exposure, or compromised infrastructure access. Encryption complements access controls by ensuring data remains protected even when storage-level security is bypassed.

Risk to mitigate

Unencrypted or selectively encrypted storage layers allow attackers with out‑of‑band access (infrastructure compromise, stolen media, snapshot abuse) to harvest sensitive data at scale. Without default encryption:

  • Data harvesting from raw media: Stolen disks, backups, or unmanaged snapshots expose full plaintext datasets.
  • Privilege boundary erosion: Platform administrators or compromised host agents can read tenant data absent cryptographic segregation.
  • Silent copy & exfiltration: Unencrypted replicas (test, analytics, export) become low-friction exfiltration channels.
  • Integrity tampering: Attackers modify dormant data (malicious DLLs, configuration, or reference data) to trigger later-stage compromise.
  • Regulatory non-compliance: Lack of systemic encryption undermines assurances required for many industry certifications.
  • Keyless recovery exposure: Disaster recovery images and cold archives retain sensitive content indefinitely in recoverable plaintext.

Failing to enforce universal encryption-at-rest increases breach scale, complicates forensic scoping, and magnifies downstream operational and legal risk.

MITRE ATT&CK

  • Collection (TA0009): data from cloud storage (T1530) by extracting unencrypted snapshots, replicas, or detached disks.
  • Defense Evasion (TA0005): indicator removal (T1070) editing or purging logs following offline media / snapshot access.
  • Impact (TA0040): data destruction (T1485) corrupting unencrypted dormant assets to disrupt downstream processes.
  • Impact (TA0040): inhibit system recovery (T1490) deleting or altering unencrypted backups and recovery catalogs.
  • Impact (TA0040): data manipulation (T1565) subtly modifying stored reference or configuration data to cause later-stage logic faults.

DP-4.1: Enable data at rest encryption by default

Ensure all data stored in Azure is encrypted at rest to protect against unauthorized access from infrastructure compromise, stolen media, or unauthorized snapshots. While most Azure services enable encryption by default, verify coverage across virtual machines, storage accounts, and databases, and enable additional encryption layers (encryption-at-host, infrastructure encryption, confidential computing, and column-level encryption) for highly sensitive workloads to meet regulatory and data sovereignty requirements.

Enable encryption for VMs and storage:

  • Enable encryption-at-host for Azure Virtual Machines to encrypt temp disks, OS disk cache, data disk cache, and ephemeral OS disks before data reaches Azure Storage. Register the EncryptionAtHost feature at the subscription level and deploy VMs using supported VM sizes (e.g., DSv3, Easv4, Dadsv5 series).
  • Enable infrastructure encryption (double encryption) for Azure Storage accounts requiring additional encryption layers. This provides two layers of AES-256 encryption with different keys at both the service and infrastructure levels—configure during storage account creation as it cannot be enabled after creation.

Deploy confidential computing and column-level encryption:

  • Deploy Azure Confidential VMs with confidential disk encryption for highly regulated workloads processing export-controlled or sensitive data. Use DCasv5/DCadsv5-series (AMD SEV-SNP) or ECasv5/ECadsv5-series (Intel TDX) with vTPM-bound disk encryption keys to ensure data remains encrypted during processing.
  • For Azure SQL Database, implement Always Encrypted to provide client-side column-level encryption for highly sensitive data (SSN, credit card numbers, medical records) where data remains encrypted even from database administrators, cloud operators, and high-privileged but unauthorized users. Use Always Encrypted with secure enclaves (Intel SGX) to enable richer queries on encrypted columns.

Monitor and enforce encryption compliance:

  • Enforce encryption compliance using Azure Policy by assigning built-in policies such as "Virtual machines should enable encryption at host," "Storage accounts should have infrastructure encryption," and "Transparent Data Encryption on SQL databases should be enabled" at subscription or management group scope.
  • Use Azure Resource Graph to query and inventory encryption configurations across your environment, identifying VMs without encryption-at-host, storage accounts without infrastructure encryption, or databases without TDE enabled.

Note: Many Azure services (Azure Storage, Azure SQL Database, Azure Cosmos DB) have data-at-rest encryption enabled by default at the infrastructure layer using service-managed keys that automatically rotate every two years. Where encryption is not enabled by default, enable it at the storage, file, or database level based on technical feasibility and workload requirements.

Implementation example

A multinational manufacturing company standardized encryption-at-rest across their Azure environment to protect ERP data, supply chain applications, and engineering trade secrets.

Challenge: Inconsistent encryption coverage left sensitive data vulnerable to infrastructure compromise and snapshot theft. Temp disk data and ephemeral storage remained unencrypted, creating compliance gaps. Without systematic encryption enforcement, engineering trade secrets and supply chain data could be exposed through stolen disks, unauthorized snapshots, or compromised host agents.

Solution approach:

  • Enable encryption-at-host for Azure Virtual Machines: Register EncryptionAtHost feature at subscription level, enable encryption-at-host for VMs using supported VM sizes (DSv3, Easv4, Dadsv5 series), encryption covers temp disks, OS disk cache, data disk cache, and ephemeral OS disks.
  • Enable infrastructure encryption (double encryption) for Azure Storage: Verify Azure Storage Service Encryption (SSE) is enabled (on by default—AES-256 encryption), for sensitive storage accounts enable infrastructure encryption during storage account creation (cannot be enabled after creation), result: two layers of AES-256 encryption with different keys.
  • Deploy Azure Confidential VMs for highly regulated workloads: Select appropriate Confidential VM series (DCasv5/DCadsv5-series for AMD SEV-SNP or ECasv5/ECadsv5-series for Intel TDX), enable confidential disk encryption with platform-managed key (binds disk encryption keys to VM's virtual TPM), enable Secure Boot and vTPM for attestation, deploy for workloads processing export-controlled technical data or highly regulated PII where data must remain encrypted during processing.
  • Implement Always Encrypted for sensitive database columns: Identify highly sensitive columns in Azure SQL Database requiring column-level encryption (SSN, CreditCardNumber, MedicalRecordNumber), generate column encryption keys (CEK) and column master keys (CMK) storing CMK in Azure Key Vault with CEK encrypting data columns and CMK encrypting CEK, enable Always Encrypted with secure enclaves (Intel SGX) to allow richer queries on encrypted data, encrypt sensitive columns using deterministic encryption (for equality lookups) or randomized encryption (maximum security), configure application connection strings with Column Encryption Setting=Enabled for transparent encryption/decryption.
  • Inventory encryption configurations with Azure Resource Graph: Query encryption status for VMs without encryption-at-host and storage accounts without infrastructure encryption, export results to CSV and assign remediation tasks to resource owners.

Outcome: Encryption-at-host addressed compliance gaps where temp disk data was previously unencrypted. Infrastructure encryption protected engineering files with two encryption layers. Confidential VMs ensured export-controlled data remained encrypted even from cloud administrators. Always Encrypted protected sensitive database columns—database administrators confirmed inability to read plaintext from encrypted columns, meeting compliance requirements.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: 3.11
  • NIST SP 800-53 Rev.5: SC-28
  • PCI-DSS v4: 3.5.1, 3.6.1
  • NIST CSF v2.0: PR.DS-1
  • ISO 27001:2022: A.8.24
  • SOC 2: CC6.1

DP-5: Use customer-managed key option in data at rest encryption when required

Azure Policy: See Azure built-in policy definitions: DP-5.

Security principle

Use customer-managed keys when regulatory compliance, contractual requirements, or data sensitivity demands direct control over encryption key lifecycle, including key generation, rotation, and revocation authority. Ensure proper key management processes are in place to handle the operational overhead.

Risk to mitigate

Relying solely on service-managed keys where regulatory, contractual, or segregation assurances demand tenant control introduces compliance and concentration risks. Without properly governed customer-managed keys (CMK):

  • Inadequate regulatory assurance: Auditors may reject evidence of cryptographic control if key custody, rotation cadence, or revocation authority can't be demonstrated.
  • Revocation latency: Inability to rapidly revoke or rotate compromised platform keys extends exposure window after credential or supply chain events.
  • Jurisdictional exposure: Data sovereignty mandates may require tenant-operated or HSM-backed keys—absence impairs regional deployment viability.
  • Cross-tenant blast radius: Multi-tenant platform key compromise can impact broad datasets when cryptographic isolation is insufficient.
  • Shadow proliferation: Ad-hoc CMK deployments without lifecycle governance lead to stale, orphaned, or weak keys.
  • Operational fragility: Poor rotation automation or missing dependency mapping causes application outages during key rollover.

Improper or omitted CMK usage weakens cryptographic assurance and undermines strategic compliance positioning for sensitive workloads.

MITRE ATT&CK

  • Credential Access (TA0006): unprotected credentials (T1552) exposed by weakly safeguarded or improperly segmented platform keys.
  • Impact (TA0040): data encrypted for impact (T1486) abusing CMK rotation / revocation to render data inaccessible.
  • Impact (TA0040): data manipulation (T1565) modifying encryption state metadata to desynchronize protection layers.
  • Exfiltration (TA0010): transfer data to cloud account (T1537) re-encrypting and exporting datasets into attacker-controlled storage.
  • Exfiltration (TA0010): exfiltration over web services (T1567) orchestrating high-volume, key-enabled bulk exports under normal service patterns.

DP-5.1: Use customer-managed key option in data at rest encryption when required

Implement customer-managed keys when regulatory compliance, data sovereignty mandates, or contractual obligations require direct control over encryption key custody, rotation schedules, and revocation authority. For workloads requiring ultimate control where even Microsoft cannot decrypt data, implement Double Key Encryption (DKE) where your organization maintains a second encryption key outside Azure. Use Azure Key Vault or Managed HSM to maintain cryptographic control while balancing the operational complexity of key lifecycle management, disaster recovery planning, and potential service availability impacts from key management errors.

Evaluate CMK requirements and provision key infrastructure:

  • Evaluate regulatory, compliance, or business requirements to determine which workloads need customer-managed keys (CMK) instead of platform-managed keys. Common drivers include data sovereignty, audit requirements, or contractual obligations for direct key custody.
  • Provision Azure Key Vault (Standard or Premium) or Azure Key Vault Managed HSM to store and manage customer-managed encryption keys. Use Managed HSM for workloads requiring FIPS 140-3 Level 3 validated hardware protection.
  • Generate encryption keys within Azure Key Vault using key generation capabilities, or import keys from on-premises HSMs using Bring Your Own Key (BYOK) for maximum portability and control.

Configure CMK and establish key hierarchy:

  • For extreme control requirements, implement Double Key Encryption (DKE) where sensitive documents require two keys for decryption: one managed by Microsoft (Azure RMS) and a second key managed exclusively by your organization on-premises or in your own external key management service. With DKE, Microsoft cannot decrypt your data even if compelled by legal process, as you control the second key required for decryption.
  • Configure Azure services (Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Encryption, etc.) to use CMK by referencing the Key Vault key URI. Enable automatic key rotation policies to reduce manual operational burden.
  • Establish a key encryption key (KEK) and data encryption key (DEK) hierarchy where the KEK (stored in Key Vault) encrypts the DEK (used by services), minimizing the impact of key rotation on service availability.
  • Document key lifecycle procedures including key rotation schedules, revocation processes for compromised keys, key retirement workflows, and disaster recovery procedures. Integrate key management into your organizational change management processes.

Note: Customer-managed keys require ongoing operational investment including key lifecycle management, access control administration, monitoring, and disaster recovery planning. Ensure operational readiness before adopting CMK, as improper key management can result in data unavailability or loss.

Implementation example

A regulated financial institution deployed customer-managed keys (CMK) across Azure services to satisfy regulatory requirements for direct cryptographic control over trading data and customer financial records.

Challenge: Regulatory auditors required demonstrated cryptographic control including key custody, rotation authority, and revocation capability. Service-managed keys couldn't provide evidence of tenant-controlled key lifecycle. Without customer-managed keys, the organization lacked ability to rapidly revoke access during security incidents and couldn't meet data sovereignty requirements for regional deployments.

Solution approach:

  • Provision Azure Key Vault Managed HSM: Create Managed HSM (FIPS 140-3 Level 3 validated) with minimum 3 HSM partitions for high availability, activate Managed HSM by exporting security domain with quorum keys (split into key fragments stored in geographically distributed offline vaults), generate encryption keys (RSA-4096 named KEK-Prod-2024) with key operations: Wrap Key, Unwrap Key, Encrypt, Decrypt.
  • Configure customer-managed keys for Azure services: For Azure Storage configure storage account to use CMK encryption type, select Key Vault Managed HSM as key source, enable user-assigned managed identity with Managed HSM Crypto Service Encryption User role; for Azure SQL Database configure SQL Database to use customer-managed key as TDE protector, select key from Managed HSM, enable auto-rotation; for Azure Cosmos DB enable customer-managed keys for Cosmos DB account, select Managed HSM key, grant Cosmos DB managed identity access.
  • Implement automated key rotation: Configure rotation policy with 90-day rotation frequency, enable automatic rotation, configure expiration notification (alert 7 days before expiration), create Azure Monitor alert for Key Near Expiry metric to notify security team.
  • Enable audit logging for compliance: Enable diagnostic logging for Managed HSM (AuditEvent logs), send logs to Log Analytics workspace with immutable storage (90-day retention for tamper-proof audit trails), query key access logs to monitor Encrypt, Decrypt, WrapKey, and UnwrapKey operations.
  • Document key lifecycle procedures: Create emergency revocation runbooks (key revocation steps, incident response contacts, recovery procedures using security domain quorum keys), test runbooks quarterly via tabletop exercises, integrate CMK operations into IT Service Management change approval workflow.

Outcome: RSA-4096 KEKs in Managed HSM encrypt service-level DEKs for Azure Storage, SQL Database, and Cosmos DB. Quarterly automated rotation minimizes downtime by re-encrypting only DEKs. Security domain quorum ensures disaster recovery even with complete regional failure.

Criticality level

Should have.

Control mapping

  • CIS Controls v8.1: 3.11
  • NIST SP 800-53 Rev.5: SC-12, SC-28
  • PCI-DSS v4: 3.5.1, 3.6.1, 12.3.2
  • NIST CSF v2.0: PR.DS-1, ID.AM-3
  • ISO 27001:2022: A.8.24
  • SOC 2: CC6.1

DP-6: Use a secure key management process

Azure Policy: See Azure built-in policy definitions: DP-6.

Security principle

Implement secure key management processes that govern the complete key lifecycle: generation, distribution, storage, rotation, and revocation. Use dedicated key vault services with strong access controls, maintain cryptographic standards, enforce separation of duties, and ensure keys are rotated regularly and revoked promptly when compromised.

Risk to mitigate

Weak or unmanaged cryptographic key lifecycles degrade the assurance provided by encryption and can enable systemic compromise. Without structured key generation, rotation, protection, and revocation:

  • Key sprawl & orphaning: Untracked keys persist beyond business need, retaining unintended decrypt authority.
  • Stale cryptography: Infrequent rotation increases exposure to algorithmic downgrade, brute-force, or side-channel advances.
  • Privilege overreach: Lack of role separation lets administrators both manage and use keys, enabling insider misuse.
  • Undetected compromise: No integrity monitoring or version lineage obscures whether keys were replaced maliciously.
  • Failed revocation: Incident response cannot cryptographically contain data access after suspected breach.
  • Inconsistent hierarchy: Missing KEK/DEK layering multiplies rotation blast radius and increases operational downtime.

Deficient key management turns encryption into a point-in-time control rather than a sustained mitigation against evolving threats.

MITRE ATT&CK

  • Credential Access (TA0006): credentials from password stores (T1555) extracting improperly stored or cached key material, or valid accounts (T1078) exploiting broad key management RBAC roles to access or rotate keys illegitimately.
  • Defense Evasion (TA0005): weaken encryption (T1600) retaining deprecated algorithms / insufficient key sizes to reduce cryptographic strength.
  • Impact (TA0040): data destruction (T1485) executing destructive purge or mishandled revocation events.
  • Impact (TA0040): data manipulation (T1565) replacing or altering key versions to redirect or disable encryption flows.

DP-6.1: Establish key management policies and infrastructure

Build a governance foundation for cryptographic key management by establishing centralized key storage, defining cryptographic standards, and selecting appropriate protection levels based on workload sensitivity. Deploy Azure Key Vault as the single source of truth for key operations while implementing comprehensive audit logging to track all key access and administrative changes for compliance and forensic purposes.

Establish centralized key management infrastructure:

  • Use Azure Key Vault as the centralized cryptographic key management service to control the complete key lifecycle: generation, distribution, storage, rotation, and revocation.
  • Define and enforce key policies specifying minimum cryptographic standards:
    • Key type: RSA (recommended: 4096-bit or 3072-bit minimum) or EC (P-256, P-384, P-521 curves).
    • Key operations: Limit permitted operations (encrypt, decrypt, sign, verify, wrap, unwrap) based on least-privilege principles.
    • Validity period: Set activation and expiration dates to enforce time-bound key usage.

Choose appropriate key vault tier:

  • Choose the appropriate Key Vault tier based on your workload's security and compliance requirements:
    • Software-protected keys (Standard & Premium SKUs): FIPS 140-2 Level 1 validated
    • HSM-protected keys (Premium SKU): FIPS 140-2 Level 2 validated (shared multi-tenant HSM backend)
    • Managed HSM: FIPS 140-3 Level 3 validated (dedicated single-tenant HSM pool)
  • For enhanced security, use Azure Key Vault Managed HSM for single-tenant, FIPS 140-3 Level 3 validated HSM protection. Managed HSM supports cryptographic domain for backup and disaster recovery.
  • Configure Azure Key Vault logging and route logs to Azure Monitor or Microsoft Sentinel to track all key access, rotation events, and administrative operations for audit and compliance purposes.

DP-6.2: Implement key lifecycle automation

Automate key rotation and establish key hierarchies to reduce operational burden, minimize human error, and enable rapid key replacement without service disruption. Implement KEK/DEK patterns that allow efficient rotation by re-encrypting small key bundles rather than entire datasets, and integrate disaster recovery procedures to maintain key availability across regional failures or catastrophic events.

Implement automated key rotation:

  • Implement automated key rotation policies in Azure Key Vault:
    • Configure rotation frequency based on compliance requirements (common intervals: 90 days, 180 days, or annually).
    • Enable rotation notifications to alert operational teams before key expiration.
    • Configure automatic rotation to generate new key versions without manual intervention.

Establish key hierarchy and BYOK:

  • Establish a key hierarchy separating Key Encryption Keys (KEK) and Data Encryption Keys (DEK):
    • Store KEKs in Azure Key Vault with restricted access controls.
    • Generate service-level DEKs, encrypted by KEKs, minimizing the blast radius of key rotation.
    • Rotating KEK only requires re-encrypting DEKs (not entire datasets), enabling efficient key rotation with zero downtime.
  • For Bring Your Own Key (BYOK) scenarios, generate keys in on-premises FIPS 140-2 Level 2+ HSMs and use the BYOK transfer key mechanism to securely import keys into Azure Key Vault or Managed HSM, maintaining cryptographic proof of key origin and custody.

Implement disaster recovery procedures:

  • Create geo-replicated Key Vaults in secondary regions.
  • Back up and restore keys to maintain key availability across regions.
  • Document and test disaster recovery procedures with defined RTO/RPO targets.

DP-6.3: Enforce separation of duties for key access

Prevent insider threats and privilege abuse by separating key management roles from cryptographic operation roles, ensuring no single identity can both create keys and use them for data encryption or decryption. Implement continuous monitoring to detect anomalous key access patterns and maintain comprehensive key inventories that enable rapid impact assessment during security incidents or compliance audits.

Enforce separation of duties:

  • Implement role-based access control (RBAC) or access policies to enforce separation of duties:
    • Separate roles for key administrators (who can create/rotate/delete keys but cannot perform cryptographic operations).
    • Separate roles for key users (who can perform encrypt/decrypt operations but cannot manage keys).
    • Example roles: Key Vault Crypto Officer (administrators), Key Vault Crypto User (applications/users).
  • Verify that no single identity has both administrative and operational key access to prevent privilege abuse.

Monitor key access and maintain inventory:

  • Integrate key access monitoring with Microsoft Sentinel to detect anomalies:
    • Unusual key access patterns (access from unfamiliar IP addresses or regions).
    • Bulk key operations (excessive operations within short time periods).
    • Off-hours administrative changes (key deletion or rotation outside business hours).
  • Maintain a key inventory tracking key name, purpose, rotation schedule, and dependent services. Review inventory regularly during security reviews.

Implementation example

A healthcare SaaS provider centralized cryptographic key management using Azure Key Vault Premium SKU with HSM-protected keys for PHI encryption across their multi-tenant platform.

Challenge: Fragmented key management across development teams led to key sprawl, inconsistent rotation practices, and difficulty tracking key usage during security incidents. Over-broad RBAC permissions allowed administrators to both manage and use keys, creating insider risk. Without automated rotation and separation of duties, the organization faced extended key compromise windows and audit compliance failures.

Solution approach:

  • Provision Azure Key Vault Premium with HSM-protected keys: Create Azure Key Vault with Premium tier to support HSM-protected keys, enable purge protection to prevent permanent deletion during retention period, enable soft delete with 90-day retention to allow recovery of accidentally deleted keys, generate RSA-3072 HSM-protected encryption keys (KEK-PHI-Prod) with hardware-backed key type.
  • Implement automated key rotation policies: Configure rotation policy with 180-day rotation frequency, enable automatic rotation and set notification to alert 30 days before expiry, create Azure Monitor action groups to notify security operations team when keys approach expiration, configure rotation action to automatically generate new key versions.
  • Configure RBAC separation of duties: Assign Key Vault Crypto Officer role to security team members (permissions: manage key lifecycle but cannot perform encrypt/decrypt operations), assign Key Vault Crypto User role to application managed identities (permissions: perform encrypt/decrypt operations only with no key management permissions), verify separation of duties by ensuring no identity has both Crypto Officer and Crypto User roles.
  • Establish KEK/DEK hierarchy for rapid key rotation: Generate application-level Data Encryption Keys (DEKs) within application code (AES-256 keys) for encrypting patient data, store encrypted DEKs alongside encrypted data, use Key Vault KEK to wrap/encrypt DEKs via WrapKey operation, retrieve and unwrap DEK using UnwrapKey operation when decrypting patient data, benefit: rotating KEK only requires re-encrypting DEKs instead of entire patient database.
  • Integrate Key Vault logs with Microsoft Sentinel: Enable diagnostic settings for Key Vault and send logs to Log Analytics workspace, create Sentinel analytics rules to detect unusual key access patterns, bulk key operations, off-hours administrative changes.
  • Bring Your Own Key (BYOK) transfer from on-premises HSM: Download BYOK transfer key from Key Vault, export key from on-premises HSM wrapped with Key Vault's BYOK transfer public key, maintain cryptographic proof of key lineage, import wrapped key to Key Vault where it arrives HSM-protected without plaintext exposure.

Outcome: RSA-3072 keys rotate every 180 days with automated notifications. RBAC separation prevents privilege abuse. KEK/DEK hierarchy enables rapid rotation by re-encrypting only DEKs. Soft delete recovers accidentally deleted keys. Microsoft Sentinel detects anomalies like unfamiliar IP access or off-hours modifications.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: N/A
  • NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
  • PCI-DSS v4: 3.6.1, 8.3.2
  • NIST CSF v2.0: PR.AC-1, PR.DS-1
  • ISO 27001:2022: A.8.24, A.8.3
  • SOC 2: CC6.1, CC6.2

DP-7: Use a secure certificate management process

Azure Policy: See Azure built-in policy definitions: DP-7.

Security principle

Manage certificate lifecycles through centralized processes that include inventory, automated renewal, strong cryptographic standards, and timely revocation. Ensure certificates for critical services are tracked, monitored, and renewed before expiration to prevent service disruptions and maintain secure encrypted communications.

Risk to mitigate

Poorly governed certificate lifecycles cause service outages, weaken encrypted channels, and permit impersonation. Without centralized inventory, policy enforcement, and automated renewal:

  • Unexpected expirations: Lapsed certificates trigger production outages, breaking APIs, identity federation, or client trust paths.
  • Weak cryptography persistence: Legacy key sizes / signature algorithms (e.g., SHA-1, RSA < 2048) remain in use beyond deprecation.
  • Wildcard & self-signed abuse: Broad-scope or unmanaged self-signed certs enable lateral impersonation and TLS downgrade risk.
  • Undetected compromise: Stolen private keys allow transparent man‑in‑the‑middle or traffic decryption until rotation.
  • Shadow certificates: Unsanctioned issuance outside approved CAs fragments governance and increases revocation blind spots.
  • Manual renewal errors: Inconsistent replacement sequencing causes trust chain mismatches and partial environment drift.

Deficient certificate management degrades encrypted assurance and introduces both reliability and security instability across critical services.

MITRE ATT&CK

  • Defense Evasion (TA0005): subvert trust controls (T1553) issuing or introducing fraudulent / rogue certificates to bypass validation.
  • Resource Development (TA0042): develop capabilities (T1587) forging certificates or tooling for future intrusion phases.
  • Defense Evasion (TA0005): weaken encryption (T1600) continuing use of obsolete signature algorithms reducing verification assurance.
  • Credential Access (TA0006): unprotected credentials (T1552) extracting private keys from insecure file stores or process memory.
  • Persistence (TA0003): modify authentication process (T1556) rewriting certificate-based auth flows to embed long-lived access.

DP-7.1: Establish certificate policies and CA integration

Define certificate governance standards and integrate trusted certificate authorities to ensure consistent cryptographic quality and automated issuance across your infrastructure. Establish policies that enforce modern key sizes, signature algorithms, and validity periods while eliminating risky practices like self-signed certificates and wildcard certificates that expand attack surfaces when private keys are compromised.

Establish certificate management infrastructure:

  • Use Azure Key Vault to centrally manage the complete certificate lifecycle: creation, import, renewal, rotation, revocation, and secure deletion.
  • Define certificate policies in Azure Key Vault to enforce organizational security standards:
    • Key type and size: RSA 2048-bit minimum (recommended: 3072-bit or 4096-bit for long-lived certificates); EC P-256 or higher for elliptic curve certificates.
    • Signature algorithm: SHA-256 or stronger (prohibit SHA-1 and MD5).
    • Validity period: Maximum 397 days for public TLS certificates (per CA/Browser Forum baseline requirements); shorter durations (90 days) recommended for reduced exposure.
    • Certificate authority: Use only approved, integrated CAs (DigiCert, GlobalSign) or your organization's private CA.

Integrate certificate authorities:

  • Use partnered Certificate Authorities integrated with Azure Key Vault for public TLS/SSL certificates:
    • DigiCert: Organization Validated (OV) TLS/SSL certificates
    • GlobalSign: Organization Validated (OV) TLS/SSL certificates
  • For private/internal services, integrate your organization's internal Certificate Authority (e.g., Active Directory Certificate Services - ADCS) with Azure Key Vault for automated certificate issuance.
  • Avoid self-signed certificates and wildcard certificates in production environments:
    • Self-signed certificates: Lack third-party validation, cannot be revoked via public CRL/OCSP, and are rejected by modern browsers/clients.
    • Wildcard certificates: Broad scope increases risk if compromised; use subject alternative name (SAN) certificates with explicit FQDNs instead.

Note: For simple scenarios, you can use Azure App Service Managed Certificates (free, auto-renewed certificates for custom domains).

DP-7.2: Implement automated certificate renewal

Eliminate service outages caused by expired certificates by automating renewal workflows that trigger well before expiration and seamlessly update certificates across dependent services without manual intervention. Configure Azure services to automatically retrieve renewed certificates from Key Vault using managed identities, reducing operational toil and eliminating the risk of forgotten manual renewals during holidays or staff transitions.

Configure automated renewal:

  • Enable automated certificate renewal in Azure Key Vault by configuring lifetime actions to trigger renewal at a specified percentage of certificate lifetime:
    • Recommended trigger: 80-90% of validity period (e.g., ~318 days for 397-day certificate).
    • Action: Automatically renew (Key Vault requests renewal from CA without manual intervention).
  • Configure notification contacts to alert administrators of upcoming certificate expirations before automatic renewal triggers.

Enable automatic certificate binding:

  • For Azure services that support automatic certificate rotation (Azure App Service, Azure Application Gateway, Azure Front Door), configure these services to automatically retrieve updated certificates from Key Vault using managed identities or service principals with appropriate Key Vault access policies:
    • Azure services will automatically bind new certificate versions when renewed (typically within 24 hours, no service restart required).
  • For applications that cannot automatically consume Key Vault certificates, implement manual certificate rotation workflows with operational runbooks and monitoring alerts to prevent expiration-related outages.
  • Maintain an inventory of all certificates in Azure Key Vault tracking certificate name, purpose, expiration date, dependent services, and renewal status.

DP-7.3: Monitor certificate lifecycle and handle revocation

Maintain continuous visibility into certificate health through automated monitoring, inventory queries, and dashboards that surface certificates nearing expiration, using deprecated cryptography, or lacking proper governance. Establish rapid revocation procedures for compromised certificates and integrate with industry threat intelligence to proactively block certificates issued by compromised certificate authorities before they enable man-in-the-middle attacks.

Configure monitoring and alerting:

  • Configure Azure Monitor alerts for certificate expiration events:
    • Create alerts at 30 days before expiration (warning notification).
    • Create alerts at 7 days before expiration (critical alert with escalation to security team).

Maintain certificate inventory and dashboards:

  • Use Azure Resource Graph to query certificate inventory:
    • Query certificates nearing expiration (within 30/60/90 days).
    • Query self-signed certificates.
    • Query certificates using deprecated algorithms (e.g., SHA-1).
  • Create certificate audit dashboards (e.g., Power BI) with visualizations:
    • Certificate expiration timeline by time bucket.
    • Self-signed certificate count by resource group.
    • Certificates using deprecated cryptographic standards.
  • Review certificate audit dashboards regularly during security review meetings (recommended: quarterly).

Establish revocation procedures:

  • Establish certificate revocation procedures for compromised or retired certificates:
    • Document revocation process (disable certificate in Key Vault, notify dependent services).
    • Maintain incident response runbooks for certificate compromise scenarios.
    • Monitor industry advisories for compromised root or intermediate CA certificates and block them promptly.

Implementation example

An enterprise with 200+ public-facing web applications centralized certificate lifecycle management using Azure Key Vault integrated with DigiCert as their Certificate Authority.

Challenge: Manual certificate renewal processes caused multiple production outages when certificates expired unexpectedly. Wildcard certificates created excessive blast radius when private keys were compromised. Fragmented certificate management across teams resulted in shadow certificates, inconsistent cryptographic standards, and delayed revocation during security incidents. Without automated renewal and centralized inventory, the organization faced compliance failures and service disruptions.

Solution approach:

  • Configure certificate authority integration with Azure Key Vault: Add DigiCert (or other partnered Certificate Authority) to Key Vault with API credentials for automated certificate requests.
  • Create certificate policies enforcing security standards: Define certificate policy with certificate name (www-contoso-com-2024), issuer (DigiCert), subject (CN=www.contoso.com), DNS names (SAN: www.contoso.com, api.contoso.com, portal.contoso.com - avoid wildcard certificates), key type (RSA 4096 bits), signature algorithm (SHA-256), validity period (397 days maximum per CA/Browser Forum baseline), configure lifetime action for auto-renewal (set trigger at 80% of certificate lifetime approximately 318 days for 397-day cert), action: automatically renew (Key Vault requests renewal from DigiCert without manual intervention).
  • Configure automatic certificate binding for Azure services: For Azure App Service import certificate from Key Vault, assign user-assigned managed identity with Key Vault Secrets User role, enable automatic certificate updates (App Service binds new certificate version within 24 hours when renewed, no restart required); for Azure Application Gateway configure listener to retrieve certificate from Key Vault, assign user-assigned managed identity with Key Vault Secrets User and Certificates User roles, Application Gateway automatically retrieves updated certificate when Key Vault renews it.
  • Configure certificate expiration alerts: Create two alert rules in Azure Monitor—30-day expiration warning (send notification to platform engineering Slack channel), 7-day expiration critical alert (open Jira ticket for manual review and send email to security team).
  • Eliminate wildcard certificates in favor of SAN certificates: Audit existing wildcard certificates (*.contoso.com) in Key Vault, replace with SAN certificates containing explicit DNS names (www.contoso.com, api.contoso.com), benefit: if private key is compromised, only listed FQDNs are affected (not all subdomains).
  • Monitor certificate expiration: Use Azure Resource Graph to query certificate inventory and identify certificates nearing expiration (within 30 days), self-signed certificates, or certificates using deprecated SHA-1 signature algorithm, review dashboard quarterly during security review meetings.

Outcome: Automated certificate renewal triggers at 80% lifetime. Azure App Service and Application Gateway retrieve updated certificates within 24 hours via managed identities (no restart required). Azure Monitor alerts notify platform engineering before expiration. SAN certificates replace wildcard certificates, reducing compromise blast radius.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: N/A
  • NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
  • PCI-DSS v4: 3.6.1, 8.3.2
  • NIST CSF v2.0: PR.AC-1, ID.AM-3
  • ISO 27001:2022: A.8.3
  • SOC 2: CC6.1, CC6.2

DP-8: Ensure security of key and certificate repository

Azure Policy: See Azure built-in policy definitions: DP-8.

Security principle

Secure key vault services through defense-in-depth controls: least-privilege access, network isolation, comprehensive logging and monitoring, backup and recovery capabilities, and HSM-backed protection where required. Key vaults are critical infrastructure that protect cryptographic keys and certificates used for encryption and authentication.

Risk to mitigate

Compromise of the key and certificate repository nullifies upstream encryption, signing, and identity assurances. Without hardened vault access, monitoring, and isolation:

  • Key exfiltration: Stolen KEKs / HSM material permits bulk decryption of stored data and traffic interception.
  • Shadow administrative access: Over-broad RBAC or policy misconfiguration enables illicit key export, purge, or version rollback.
  • Silent tampering: Malicious key replacement enables transparent man‑in‑the‑middle or forged code/signatures.
  • Network exposure: Public endpoint abuse (credential stuffing, API probing) increases attack surface for brute-force or token replay.
  • Accidental destructive actions: Missing soft delete / purge protection leads to irreversible cryptographic data loss.
  • Insufficient audit lineage: Lack of immutable logs impairs incident response and regulatory evidentiary needs.
  • Unsegmented tenancy: Co-mingled application keys broaden lateral movement blast radius after a single identity compromise.

Repository weaknesses rapidly propagate into systemic confidentiality, integrity, and availability failures across dependent workloads.

MITRE ATT&CK

  • Credential Access (TA0006): unprotected credentials / credential stores (T1552 / T1555) obtained through misconfigured vault role or network policies.
  • Defense Evasion (TA0005): adversary-in-the-middle (T1557) capturing vault-bound traffic for key/cert interception, or weaken encryption (T1600) replacing strong keys with attacker-controlled material.
  • Privilege Escalation (TA0004): valid accounts (T1078) exploiting over-broad vault operator roles to enumerate and alter secrets.
  • Impact (TA0040): data destruction / inhibit recovery (T1485 / T1490) performing destructive purge sequences that prevent restoration.

DP-8.1: Implement access controls for Key Vault

Protect the cryptographic foundation of your infrastructure by enforcing strict identity-based access controls that prevent unauthorized key access, limit administrative privileges to justified time windows, and eliminate credential storage through managed identities. Implement separation of duties between key administrators and key users to prevent any single compromised identity from both managing and exploiting cryptographic material.

Implement RBAC and separation of duties:

  • Implement Azure RBAC for Key Vault to enforce least-privilege access control:
    • For Azure Key Vault Managed HSM: Use local RBAC at the individual key, secret, and certificate level with built-in roles (Managed HSM Crypto Officer, Crypto User, Crypto Auditor).
    • For Azure Key Vault Standard/Premium: Create dedicated vaults per application or environment to enforce logical separation and assign RBAC roles (Key Vault Administrator, Secrets Officer, Certificate Officer) with application-specific scope.
  • Enforce separation of duties: Separate roles for key management (who can create/rotate keys) from cryptographic operations (who can use keys for encrypt/decrypt).

Use managed identities and JIT access:

  • Use managed identities for Azure resources (App Services, VMs, Azure Functions, etc.) to access Key Vault instead of storing credentials in application code or configuration files. Managed identities eliminate credential storage and rotation complexity.
  • Implement Azure AD Privileged Identity Management (PIM) for just-in-time administrative access to Key Vault:
    • Configure eligible assignments for Key Vault Administrator role (not permanent assignments).
    • Require justification, MFA, and approval for activation.
    • Set maximum activation duration (e.g., 8 hours).
    • Conduct regular access reviews to revoke unnecessary standing privileges.

DP-8.2: Harden Key Vault network security

Eliminate internet-facing attack surfaces by routing all Key Vault access through private endpoints within your virtual networks, preventing credential stuffing, brute-force attempts, and reconnaissance from external threat actors. Where public access is unavoidable for CI/CD scenarios, implement strict IP allowlisting and firewall rules to create the smallest possible exposure window.

Deploy Private Link and configure firewall:

  • Secure network access to Azure Key Vault using Azure Private Link to establish private connectivity from VNets without exposing Key Vault to the public internet.
  • Configure Key Vault firewall to restrict access to specific IP ranges or VNets for scenarios where Private Link is not feasible:
    • Disable public access where possible (Key Vault only accessible via private endpoint).
    • If public access is required (e.g., for CI/CD pipelines), allow access from selected networks only with narrow IP allowlists.
  • Create and link private DNS zones (e.g., privatelink.vaultcore.azure.net) to VNets to ensure proper DNS resolution for private endpoints.

DP-8.3: Enable Key Vault protection and monitoring

Implement defense-in-depth protections that prevent irreversible cryptographic data loss through soft delete and purge protection while using HSM-backed keys for production workloads requiring FIPS-validated security. Deploy comprehensive monitoring with Microsoft Defender for Key Vault and Microsoft Sentinel to detect anomalous access patterns, unusual key operations, and administrative anomalies that indicate compromise, insider threats, or reconnaissance activities targeting your cryptographic infrastructure.

Enable soft delete and purge protection:

  • Enable soft delete and purge protection on all Azure Key Vaults to prevent accidental or malicious deletion of keys, secrets, and certificates:
    • Soft delete allows recovery within a retention period (default: 90 days).
    • Purge protection prevents permanent deletion during retention period.
    • Enforce these settings with Azure Policy using built-in policies: "Key vaults should have soft delete enabled" and "Key vaults should have purge protection enabled" (deployIfNotExists effect).
  • Implement key lifecycle policies to avoid cryptographic erasure of data:
    • Before purging encrypted data, verify that encryption keys are retained for the required data retention period.
    • When decommissioning keys, use disable operation instead of delete to prevent accidental data loss while maintaining key metadata for audit purposes.
    • Create and test Key Vault backup procedures for disaster recovery scenarios.

Use HSM-backed keys and BYOK:

  • Use HSM-backed keys for production workloads requiring strong cryptographic protection:
    • Azure Key Vault Premium: RSA-HSM and EC-HSM keys protected by FIPS 140-2 Level 2 validated HSMs (shared multi-tenant).
    • Azure Key Vault Managed HSM: RSA-HSM and EC-HSM keys protected by FIPS 140-3 Level 3 validated HSMs (dedicated single-tenant pools).
  • For Bring Your Own Key (BYOK) scenarios, generate keys in on-premises FIPS 140-2 Level 2+ HSMs and use the BYOK transfer key mechanism to securely import keys into Azure Key Vault, maintaining cryptographic proof of key origin and custody.

Enable monitoring and threat detection:

  • Enable diagnostic logging for Azure Key Vault and route logs to Azure Monitor, Log Analytics, or Microsoft Sentinel to capture all management plane and data plane operations. Monitor for suspicious activities including unusual key access patterns, failed authentication attempts, and administrative changes.
  • Enable Microsoft Defender for Key Vault to detect anomalous access patterns, unusual key operations, and potential threats such as credential abuse, suspicious key retrievals, or administrative anomalies. Integrate Defender for Key Vault alerts with incident response workflows.
  • Integrate Key Vault logs with Microsoft Sentinel to create analytics rules for detecting anomalies such as unusual regional access, potential brute force attempts, or suspicious administrative operations. Implement automated response playbooks to isolate compromised identities and notify security teams.

Note: All Key Vault SKUs prevent key export by design; cryptographic operations are performed within the secure HSM boundary. Never export or store keys in plaintext outside Azure Key Vault.

Implementation example

A multinational technology company implemented defense-in-depth security for their Azure Key Vault infrastructure protecting encryption keys, API secrets, and TLS certificates for 500+ microservices.

Challenge: Over-broad RBAC permissions allowed developers direct access to production Key Vaults, creating insider risk and compliance violations. Public internet exposure enabled credential stuffing attacks and reconnaissance attempts. Without comprehensive monitoring and automated response, suspicious key access patterns went undetected. Lack of soft delete and purge protection risked permanent cryptographic data loss during incidents.

Solution approach:

  • Deploy dedicated Key Vaults for logical segmentation: Create Key Vault per environment and business unit with naming convention kv-{businessunit}-{environment}-{region} (e.g., kv-finance-prod-eastus2, kv-finance-dev-eastus2), deploy in separate resource groups per environment to enforce isolation (compromised dev service principal cannot access production keys).
  • Configure RBAC for least-privilege access: For nonproduction Key Vaults (dev/staging) assign Key Vault Secrets User (read-only) to developer security groups—developers can read secrets in dev/staging but have zero access to production Key Vaults; for production Key Vaults assign Key Vault Secrets User to CI/CD service principals (Azure DevOps pipeline managed identities), limit scope to specific named secrets, no interactive developer access to production keys.
  • Harden network security with Azure Private Link: Deploy private endpoints for Key Vault (select VNet and subnet, create private DNS zone privatelink.vaultcore.azure.net and link to VNet), configure Key Vault firewall (disable public access with Key Vault only accessible via private endpoint, if public access required for CI/CD allow access from selected networks only with approved Azure VNet subnets and CI/CD agent IP address ranges).
  • Enable Microsoft Defender for Key Vault: Enable Microsoft Defender for Key Vault at subscription level, Defender monitors anomalies including unusual geographic access, suspicious enumeration (rapid list operations indicating reconnaissance), abnormal administrative operations (bulk secret deletions).
  • Integrate with Microsoft Sentinel for automated response: Add Microsoft Defender for Cloud data connector to Sentinel, create Sentinel Analytics rules for unusual regional access, potential brute force, suspicious administrative operations, configure automated response playbooks to disable suspicious identities and notify security teams.
  • Stream diagnostic logs to Log Analytics: Enable diagnostic logging for Key Vault with AuditEvent (all key/secret/certificate operations), AllMetrics (usage frequency, latency), send to Log Analytics workspace with 2-year retention, create custom KQL queries for anomaly detection including potential brute force detection (10+ unauthorized attempts in 5 minutes), disabled soft delete operations (sabotage indicator).
  • Implement Just-In-Time admin access with Azure AD PIM: Configure eligible assignments for Key Vault Administrator role (add security team members as Eligible not permanent assignment, require Justification and MFA for activation, set maximum activation duration 8 hours, require Approval from senior security architect), conduct quarterly access reviews for all Key Vault Administrator role assignments; revoke unnecessary access.

Outcome: Dedicated Key Vaults per environment enforce segmentation. RBAC limits developers to read-only nonproduction access. Private Link eliminates public internet exposure. Microsoft Defender detects anomalies. Sentinel playbooks automatically disable suspicious identities. PIM enables just-in-time admin access, reducing standing privileges significantly.

Criticality level

Must have.

Control mapping

  • CIS Controls v8.1: N/A
  • NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
  • PCI-DSS v4: 3.6.1, 8.3.2
  • NIST CSF v2.0: PR.AC-1, PR.DS-1
  • ISO 27001:2022: A.8.3, A.8.24
  • SOC 2: CC6.1, CC6.2
  • Last updated on