In May 2026, The Hacker News reported a documented incident in which a single cached AWS access key exposed 98% of cloud entities within one organization. The attacker did not bypass a firewall or exploit application code. They used one stale credential to walk laterally through connected cloud resources. For a mid-market manufacturer with ERP integrations, EDI connectors, and plant IoT pipelines all running on AWS, that is not an abstract security scenario — it is a description of what your integration architecture looks like today.
Cloud Identity Risk: What the Data Shows
The incident is not an outlier. According to Cybersecurity Dive's coverage of a ReliaQuest report from November 2025, identity-related risks are the top concern in cloud environments — and 44% of valid alerts generated by cloud security tools were identity-related, making it the single largest alert category by type.
The Cloud Security Alliance's State of Cloud and AI Security 2025 survey identifies insecure identities and risky permissions as the top cloud security risk overall. Among organizations that experienced a confirmed cloud-related breach, CSA found three of the top four root causes were identity-related: excessive permissions (31%), inconsistent access controls (27%), and weak identity hygiene (27%). Those figures come from CSA's own survey methodology and are not independently corroborated by a federal source, but the pattern is consistent with ReliaQuest's independent alert data.
The Qualys Cloud Security Forecast 2026 also identifies identity and permissions as primary drivers of cloud risk — though those findings come from Qualys' own blog and should be read as vendor-reported analysis rather than independent research.
Across these three separate reporting frameworks, the pattern is structural: cloud identity mismanagement has become the dominant attack surface in cloud environments, not a cyclical spike.
Why Manufacturers Are Structurally Exposed
Enterprise security teams build identity governance programs. Mid-market manufacturers build integrations.
When a manufacturer connects an ERP system — SAP Business One, Epicor, Infor, Oracle NetSuite — to AWS-hosted storage, APIs, or data pipelines, the implementation team creates service accounts and API keys to make the integration work. Those credentials are scoped to get the job done at launch and rarely revisited. The same pattern repeats for EDI translation gateways connecting to trading partners and for plant IoT telemetry pipelines pushing sensor data into cloud analytics environments.
The result is identity sprawl that accumulates silently. A service account created during an ERP go-live two years ago may still carry permissions spanning order management, inventory data, and production scheduling — not because anyone decided it should, but because no one reviewed it after launch.
A 2–4 person IT team has no realistic capacity to detect permission drift across these workloads in real time without dedicated tooling. Most mid-market manufacturers have neither the tooling nor the process. That gap is exactly what the attack pattern documented in May 2026 exploits.
The Specific Attack Path
The lateral movement sequence follows a predictable pattern. An attacker obtains one valid credential — through phishing, a compromised vendor, an exposed configuration file, or a leaked environment variable in a CI/CD pipeline. If that credential belongs to a service account with broad AWS permissions, the attacker can enumerate adjacent resources: S3 buckets, Lambda functions, database connections, other IAM roles that trust the compromised identity.
The 2023 MOVEit campaign, documented by the CSA, demonstrated this at scale: identity exploitation enabled attackers to move across multiple connected systems within a single breach event. The same sequence applies to any manufacturer whose ERP connector, EDI gateway, or IoT pipeline runs under a service account with unconstrained AWS permissions.
The operational consequence is not limited to data theft. A compromised credential with write access to an ERP integration layer can corrupt order data, manipulate inventory records, or disrupt production scheduling before any alert reaches an IT inbox. Downtime from a credential-based attack does not announce itself in advance.
The Integration Chain This Exposes
The architecture connecting manufacturing operations to cloud infrastructure creates a chain of trust. Each link — ERP connector to AWS, EDI gateway to AWS, IoT pipeline to cloud storage — depends on a credential. If any credential in that chain is stale, over-permissioned, or stored insecurely, the entire chain becomes exploitable from that single weak point.
This is not a firewall problem or a network perimeter problem. It is a permissions governance problem. The question is not "are we protected at the perimeter?" It is: what can each service account actually access, and when did anyone last verify that?
Two Assumptions Worth Revisiting
"We set up MFA, so we're covered." Multi-factor authentication protects human login sessions. It does not protect service accounts, API keys, or cached tokens that authenticate programmatically. An attacker who obtains an API key bypasses MFA entirely because the key authenticates without a login flow. MFA is not a substitute for service account hygiene.
"Our ERP vendor handles security." ERP vendors secure their application layer. The IAM roles, service accounts, and API keys connecting their application to your AWS environment are yours to manage. Vendor documentation may describe best practices; enforcement is the operator's responsibility.
Neither assumption holds under the attack pattern documented in May 2026.
What to Audit Now
The AWS IAM credential report is a native, no-cost tool that lists every access key in your account, when it was last used, and whether it is active. The IAM access advisor shows which permissions have actually been exercised by each role in the past 90 days. Together, these two outputs reveal the gap between what credentials can do and what they actually need to do.
Run both tools across every service account and API key connected to manufacturing workloads. Flag and prioritize:
- Any API key not rotated in 90+ days — especially those attached to ERP connectors or EDI gateways
- Any IAM role with permissions broader than the workload's documented function — if the EDI gateway role has S3 write access beyond its EDI bucket, that is excess permission
- Any credential hardcoded in scripts, configuration files, or environment variables — these belong in AWS Secrets Manager, not in plaintext
- Any human account accessing production AWS environments without MFA enforced — separate from service account hygiene but equally critical
- Any service account shared across multiple integration workloads — shared credentials mean a single compromise affects every workload that trusts that identity
The goal is not perfection on day one. The goal is identifying which credentials carry cross-workload permissions and which have not been reviewed since initial deployment. Those are the highest-risk identities and the most likely to be sitting unreviewed in your environment right now.
What to Watch Next
Cyber insurance carriers are increasingly requiring documented MFA enforcement and credential rotation policies at renewal. If your next renewal is within six months, complete this audit before the renewal process begins. Undocumented identity hygiene failures discovered post-breach complicate claims.
ERP vendors including SAP, Epicor, Infor, and Oracle publish IAM best-practice guidance for AWS-hosted and AWS-integrated deployments. If your current integration predates that guidance, the permission scopes used at implementation likely do not reflect current recommendations.
There are also reports of a vulnerability connected to Fluent Bit — an open-source log processing tool used in some cloud environments — that may affect AWS, Azure, and Google Cloud configurations. Those reports come from a regional MSP blog without a linked CVE or CISA advisory, so no specific technical action is warranted yet. Watch the CISA Known Exploited Vulnerabilities catalog for any Fluent Bit entry; if one appears, it becomes a concrete patching trigger for manufacturers using log processing in cloud pipelines.
The IAM credential report takes minutes to pull. The permission review that follows is a day's work for a small IT team. Neither requires a capital budget. Both are worth completing before the next ERP upgrade cycle or cloud workload expansion adds more identities to an already-unaudited environment.