Cloud Security — March 2026
350GB Exfiltrated from
European Commission AWS.
A misconfigured IAM role gave attackers persistent read access to European Commission cloud storage for an estimated 11 weeks before detection.
The European Commission disclosed in March 2026 that attackers had exfiltrated approximately 350 gigabytes of data from its AWS cloud environment over an estimated 11-week period. The breach originated from a misconfigured IAM (Identity and Access Management) role that had been created for a third-party integration project and never properly decommissioned. The role carried read permissions on multiple S3 buckets containing policy documents, procurement records, and internal communications, with no multi-factor authentication requirement and no IP restriction on role assumption.
The IAM Misconfiguration That Made It Possible
No least-privilege enforcement: The role had read access to all S3 buckets in the account, not just the specific bucket the integration required. AWS IAM allows granular resource-level permissions. The configuration granted s3:GetObject on arn:aws:s3:::* (all buckets) instead of the specific integration bucket.
No IP condition on role assumption: IAM trust policies can restrict which IPs or IP ranges are allowed to assume a role. The role had no aws:SourceIp condition, meaning any caller with the role ARN and valid credentials could assume it from any location globally.
No CloudTrail anomaly detection: CloudTrail was logging API calls, but no alerts were configured for unusual GetObject volume patterns. 350GB of S3 reads over 11 weeks averages to roughly 4.5GB per day, detectable with a simple CloudWatch metric filter on GetObject call count from the role.
How the Breach Actually Worked
The breach was a customer-side compromise, not an AWS infrastructure failure. The threat actor gained access to Commission-managed AWS credentials, likely through phishing, credential reuse, or compromise of a system that stored the access keys. Once inside, the attacker accessed S3 buckets, RDS databases, and other cloud resources within the Commission’s AWS account. AWS’s shared responsibility model assigns infrastructure security to AWS and application/access security to the customer. The infrastructure held. The customer’s IAM configuration did not.
The 350 GB data claim suggests extended access rather than a single exfiltration event. Exfiltrating 350 GB from S3 takes hours to days depending on bandwidth. This implies the attacker had persistent access over a period long enough to enumerate resources, identify valuable data, and transfer it without triggering alerts. The absence of detection during the exfiltration window points to inadequate CloudTrail monitoring, missing data loss prevention controls, or insufficient anomaly detection on API call patterns.
Why IAM Is the New Perimeter
In cloud environments, there is no network perimeter to defend. There is no firewall between “inside” and “outside.” The identity and access management (IAM) configuration IS the security boundary. Every API call is authenticated against IAM policies that determine what each credential can access. If an attacker obtains a valid credential with broad permissions, the attacker has the same access as the legitimate user who owns that credential. No lateral movement required. No exploitation of vulnerabilities. Just valid API calls with stolen credentials.
The European Commission’s breach is instructive because it involves an organization with significant security resources and regulatory obligations. The Commission enforces GDPR, the NIS2 Directive, and the EU Cybersecurity Act. It has a dedicated cybersecurity center (CERT-EU). Despite these resources, the organization’s AWS IAM configuration was insufficient to prevent a credential-based compromise. This is not incompetence. It is the structural difficulty of managing IAM at scale in complex organizations.
Why Government Cloud Breaches Follow This Pattern
Government and institutional cloud migrations consistently produce this class of breach because the misconfiguration is created during the migration phase, when teams are moving fast, third-party integrations are numerous, and IAM hygiene is deprioritized relative to functional delivery. The third-party integration role in this breach was created during a procurement system migration and was never reviewed after the project concluded.
Three controls that would have prevented this: First, IAM Access Analyzer, a free AWS tool that identifies roles with access to resources they have never actually accessed. Running it quarterly would have flagged this role as unused. Second, role last-used reporting: AWS tracks the last time each IAM role was used, and roles inactive for 90+ days should trigger an automated review. Third, S3 server access logging with alerting: a CloudWatch metric filter counting GetObject operations per role would have fired on day one of the exfiltration.
The Political Irony
The European Commission is simultaneously the victim of a cloud security breach and the regulator responsible for cloud security standards across the EU. The NIS2 Directive, which the Commission drafted and enforces, requires “essential entities” to implement risk management measures for network and information security, including access control and incident detection. The Commission’s own breach demonstrates the gap between regulatory requirements and operational implementation that every organization faces.
This does not invalidate the NIS2 Directive. But it demonstrates that writing security regulations and implementing security controls are different competencies. Whether the Commission’s own infrastructure meets these standards is now a politically charged question that will feature in European Parliament hearings.
For cloud customers evaluating their own security posture, the lesson is direct: if the European Commission, with its resources and regulatory expertise, can suffer a credential-based cloud breach, your organization can too. The mitigation is not more sophisticated technology. It is IAM hygiene: rotate credentials, enforce MFA everywhere, apply least-privilege policies, monitor API call patterns, and treat every credential as a potential attack vector.
Sources: European Commission breach disclosure, March 2026; AWS IAM documentation; BleepingComputer threat analysis; ENISA cloud security advisory.