CIO Brief: How One AWS Setting Answers the Capital One Breach
Retrospective: this article looks back at events from November 2019, written in 2026 with the benefit of hindsight.
The short version: After Capital One's 2019 breach, AWS released a setting — IMDSv2 — that blocks the technique the attacker used to steal cloud credentials. It is free and effective. But it is optional, so it only protects companies that turn it on.
Why this matters at the leadership level
When a cloud provider releases a direct fix for a famous breach technique, regulators, auditors and plaintiffs' lawyers reasonably expect customers to adopt it. Failing to enable a well-known, free protection is hard to defend after an incident.
The business impact
- Breach prevention for one of the most damaging AWS attack paths.
- Audit and insurance expectations: provider-recommended controls are increasingly checked.
- Low cost: mostly engineering time to update older software.
Questions to ask your team
- What percentage of our cloud servers require IMDSv2?
- Are new servers forced to use it automatically?
- What other provider-recommended protections released after major breaches have we not yet adopted?
What good looks like
IMDSv2 required on all instances, enforced for new ones by policy, and a regular review of new security features released by your cloud providers.
The decision
Ask for the current IMDSv2 coverage percentage and a date to reach 100%. Then ask the broader question: which other free provider safeguards are we not using?
- AWS Launches IMDSv2 (Nov 2019): Closing the Capital One Attack Path Platform Changes
- How to Migrate an EC2 Fleet to IMDSv2 Without Breaking Applications How-To & Hardening
- IMDSv2 Enforcement Checklist With SCPs and Launch Templates How-To & Hardening