How do you detect EBS default encryption being disabled in AWS?

What to monitor in AWS to catch EBS default encryption being turned off

Detecting this change starts with the control plane, not the storage layer. The key signal is a configuration or management event that alters the default EBS encryption setting, so your detection should watch for attempted changes, who made them, and whether they occurred in a region where encryption by default is expected.

That alert should not fire on the setting alone. Pair it with a check for whether newly created volumes are actually unencrypted after the change, because the operational risk is the real-world effect, not just the API call. If the account is part of a governed AWS estate, tie the event to your approved change process and policy baseline.

For broader AWS hardening, AWS Security Guide is the natural parent reference for the surrounding monitoring model, including AWS Config, CloudTrail and account-level guardrails.

Why disabled default encryption becomes a security problem quickly

Default encryption is a preventative control, so disabling it creates a gap at the point of volume creation. The issue is especially serious when teams assume encryption is still automatic, because an unencrypted volume can be created silently by automation, a human operator, or a compromised identity with the right permissions.

From a detection perspective, that means you need both change detection and outcome verification. A single setting flip may indicate configuration drift, but the security impact appears when an unencrypted EBS volume is actually provisioned or attached to a workload that stores sensitive data.

When storage encryption is the subject, Encryption Guide helps frame the difference between a policy setting, encryption at rest, and the practical need to verify that encryption is active on the asset itself.

How to confirm whether the change was legitimate or abusive

Not every configuration change is malicious, but every unexpected change deserves validation. Review the principal that made the change, the region affected, the timing against approved maintenance, and whether the action came from a console session, automation role, or delegated administrative path.

Then compare the change against surrounding activity. A legitimate operations task usually has a matching ticket, a known maintenance window, and no follow-on creation of unencrypted volumes. A suspicious event often has none of those, or it is paired with other control changes that reduce visibility or weaken policy enforcement.

If you want a detection pattern that generalises beyond this setting, NIST Cybersecurity Framework 2.0 provides a useful structure for linking configuration change, monitoring, and response rather than treating them as separate problems.

Risk and Threat Considerations

Disabling EBS default encryption is a low-friction way to create data exposure, especially in fast-moving accounts where teams assume guardrails will compensate for human error. The main threat is not just accidental noncompliance, but also deliberate abuse of a privileged path to create or persist unencrypted storage outside policy.

Failure mechanism: A permitted change to the default encryption setting removes the automatic protection at volume creation, and unencrypted volumes can then be provisioned before anyone notices the drift.

Impact: Sensitive data may be stored without encryption at rest, increasing exposure during snapshot handling, backup workflows, replication, incident response, or unauthorized access to the underlying storage.

Practitioner Guidance

What to verify: Confirm that your alerting covers both the configuration change and the downstream state of newly created volumes. The strongest signal is a paired detection, change to the default plus evidence that unencrypted volumes were created after it.

Decision rule: If the change was not explicitly authorised, treat it as a control failure first and an incident second. Re-enable the default, review recent volume creation events, and check whether any sensitive systems were launched into an unencrypted state.

Practitioner takeaway: The important question is not whether someone toggled a setting, it is whether that toggle created a window in which storage could be created unencrypted without immediate detection.

Related resources from NHI Mgmt Group

• How do you detect AWS Config recorders being disabled?
• How do you detect AWS GuardDuty being disabled or modified?
• How do you detect LLMjacking activity in AWS CloudTrail?
• How do you detect abuse of AWS console GetSigninToken?