Overview
In any dynamic Azure environment, data governance often centers on active workloads like running virtual machines and databases. However, a significant amount of data resides in dormant assets, particularly unattached managed disks. These idle resources are frequently forgotten after a Virtual Machine (VM) is deleted or detached, creating a critical blind spot in cloud security and cost management.
By default, Azure encrypts all managed disks using Platform-Managed Keys (PMK). While this protects against the physical theft of hardware in a datacenter, it offers no defense against an attacker who gains valid Azure credentials. If a compromised account has permission to mount a disk, the platform transparently decrypts the data.
This is where Customer-Managed Keys (CMK) provide a vital layer of security. Using CMK gives you direct control over the encryption keys stored in your own Azure Key Vault. This approach ensures that even if an attacker compromises an administrative account, they cannot access the disk’s data without separate authorization to the encryption key, effectively neutralizing a common attack vector.
Why It Matters for FinOps
Failing to properly secure idle resources has direct consequences for cost, risk, and operational efficiency. Unattached disks are a form of waste—they incur storage costs every month without delivering any business value. From a FinOps perspective, they represent a recurring, unnecessary expense that clouds unit economics and complicates chargeback models.
The security risk is even greater. An unattached disk encrypted only with default PMK is a liability. A single compromised set of credentials could be used to attach the disk to another VM and exfiltrate sensitive data, leading to significant regulatory fines, forensic investigation costs, and severe reputational damage. For organizations subject to compliance frameworks like PCI-DSS, HIPAA, or CIS Benchmarks, using CMK is often a non-negotiable requirement.
Finally, a lack of governance around these idle resources creates operational drag. Engineering teams spend valuable time manually identifying and cleaning up this “zombie infrastructure” instead of focusing on innovation. A robust policy for managing unattached disks is a hallmark of a mature cloud financial management practice.
What Counts as “Idle” in This Article
In this article, an “idle” resource refers to an Azure Managed Disk that exists within a subscription but is not currently associated with any running or stopped Virtual Machine. The disk’s state is officially marked as Unattached.
These disks are often the byproduct of routine operations. When a VM is deleted, its associated OS and data disks are not deleted by default. They become orphaned assets, silently consuming budget and expanding the organization’s attack surface. Other common sources include disks retained for forensic analysis or temporary disks created during disaster recovery tests that were never cleaned up.
Common Scenarios
Scenario 1
Decommissioned VMs: This is the most frequent cause of unattached disks. An engineer decommissions a VM through the portal or a script but overlooks the option to delete the associated disks. The disks remain in the resource group as forgotten assets, still holding potentially sensitive application or user data.
Scenario 2
Forensic and Backup Retention: When a security incident occurs, teams often detach a VM’s disk to preserve it as evidence for forensic analysis. Similarly, during a backup verification or disaster recovery drill, a disk may be restored from a snapshot and then left unattached after the test is complete. These disks contain exact copies of production data and require the highest level of security.
Scenario 3
Golden Images: DevOps and platform engineering teams create and maintain “golden image” disks that serve as standardized templates for new VM deployments. While not attached to a running instance, these images contain proprietary software configurations, application code, and sometimes embedded secrets. If compromised, an attacker could exploit vulnerabilities or reverse-engineer your applications.
Risks and Trade-offs
The primary risk of leaving unattached disks secured only with platform-managed keys is credential compromise. An attacker with sufficient permissions can simply attach the disk to a VM under their control, and Azure will automatically handle the decryption, giving them full access to the data.
Implementing CMK introduces a separation of duties. Accessing the data requires permissions to both the disk resource and the encryption key in Azure Key Vault. This significantly raises the bar for an attacker. The main trade-off is a minor increase in operational complexity. Teams must manage the lifecycle of encryption keys and configure Disk Encryption Sets. However, this trade-off is minimal compared to the immense security and compliance benefits it provides. Proper key management is crucial—if a key is lost or mismanaged, it could render the data on the disk permanently inaccessible.
Recommended Guardrails
Effective governance is key to preventing the proliferation of insecure, idle disks. Rather than relying on manual cleanup, organizations should implement automated guardrails.
Start by establishing a clear tagging policy that assigns an owner and a review date to every managed disk. This creates accountability and simplifies showback. Use Azure Policy to enforce security standards at scale. For instance, you can implement a policy that denies the creation of any new managed disk that is not configured to use a specified Disk Encryption Set for CMK.
Furthermore, develop an automated lifecycle management process. A simple automation script or Logic App can identify disks that have been unattached for a defined period (e.g., 30 days), notify the owner, and schedule them for deletion if no action is taken. This proactive approach reduces both cost waste and security risk.
Provider Notes
Azure
Controlling encryption for unattached disks in Azure involves orchestrating a few key services. The primary resources are Azure Managed Disks, which are the block-level storage volumes for Azure VMs.
To implement customer-managed encryption, you must use Azure Key Vault, a cloud service for securely storing and accessing secrets, certificates, and cryptographic keys. For data safety, your Key Vault should always have Soft Delete and Purge Protection enabled.
The link between your Key Vault and your disks is a resource called a Disk Encryption Set (DES). A DES is granted permissions to access a specific key in your Key Vault, and you then associate your managed disks with that DES to enforce CMK encryption.
Binadox Operational Playbook
Binadox Insight: Unattached disks are more than just storage waste; they are a hidden liability. Enforcing Customer-Managed Key (CMK) encryption transforms them from a security risk into a controlled, auditable asset, aligning your security posture with FinOps principles.
Binadox Checklist:
- Inventory all Azure subscriptions to identify existing unattached disks and their current encryption status.
- Establish a mandatory ownership tagging policy for all storage resources to ensure accountability.
- Deploy a central Azure Key Vault with purge protection and soft delete enabled for managing encryption keys.
- Implement an Azure Policy to enforce the use of CMK for all newly created managed disks.
- Develop an automated lifecycle policy to alert on and eventually remove disks that remain unattached beyond a set threshold.
Binadox KPIs to Track:
- Percentage of unattached disks encrypted with CMK.
- Total monthly cost attributed to unattached disk storage.
- Mean Time to Remediate (MTTR) for newly orphaned or non-compliant disks.
- Count of policy violations for non-CMK disk creation attempts.
Binadox Common Pitfalls:
- Forgetting to enable purge protection on Key Vault, creating a risk of accidental and permanent key deletion.
- Misconfiguring the permissions for the Disk Encryption Set’s managed identity, leading to VM boot or disk attachment failures.
- Lacking an automated cleanup process, which allows storage waste and risk to accumulate over time.
- Focusing only on newly created disks while ignoring the security risk posed by the existing inventory of unattached disks.
Conclusion
Securing unattached Azure Managed Disks with Customer-Managed Keys is a fundamental practice for any organization serious about cloud security and financial governance. It moves beyond Azure’s default protections to address the real-world threat of account compromise and provides the granular control and auditability required by modern compliance frameworks.
By implementing the guardrails and operational playbooks outlined in this article, you can transform these idle resources from a hidden liability into well-governed assets. The first step is to gain visibility: begin by inventorying your environment to understand the scope of the challenge and build a remediation plan.
7-day free trial