Notifications
Clear all
Topic starter
19/08/2026 3:50 pm
TL;DR: Cloud migrations are expanding external attack surfaces faster than annual testing can track, with misconfigurations, stale DNS, exposed secrets, and inherited assets creating new entry points, according to Sprocket Security and cited industry research. The control problem is not the migration itself but the assumption that a point-in-time test still represents a dynamic cloud environment.
NHIMG editorial — based on content published by Sprocket Security: cloud migration attack surface expansion and the limits of annual testing
By the numbers:
- The average time to identify a breach in cloud environments was 194 days, according to IBM's Cost of a Data Breach Report 2024.
- A 2023 GitGuardian report found that secrets exposure in public GitHub repositories grew 67% year over year, according to GitGuardian.
Questions worth separating out
Q: How should security teams test cloud environments during migration?
A: They should test continuously, not annually, and tie each assessment to change events such as new workloads, DNS updates, exposed APIs, or decommissioning.
Q: Why do cloud migrations create more attack surface than on-premises changes?
A: Because cloud changes are faster, more distributed, and easier to make outside central review.
Q: What do security teams get wrong about cloud inventory and compliance?
A: Teams often assume inventory is accurate if a periodic scan eventually finds the resource.
Practitioner guidance
- Trigger security review on every cloud change event Treat new workloads, DNS changes, API deployments, and storage exposure as automatic testing triggers rather than waiting for the next annual assessment.
- Continuously validate cloud identity scope Review service accounts, IAM roles, and hard-coded credentials during migration and after go-live.
- Couple decommissioning with external cleanup Remove DNS records, public endpoints, and abandoned cloud references at the same time you retire the resource.
What's in the full article
Sprocket Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Example attack surface changes observed during cloud migrations, including the asset types that appeared after assessment windows closed.
- Specific takeover and decommissioning scenarios involving S3 buckets, subdomains, and exposed cloud services.
- The testing model Sprocket uses to combine external reconnaissance with human validation of findings.
- Practical remediation sequencing for teams that need to reduce exposure while migration work is still in progress.
👉 Read Sprocket Security's analysis of how cloud migration expands attack surface →
Cloud migration exposure: is your testing keeping up with change?
Explore further
19/08/2026 4:26 pm
Cloud migration creates control drift before it creates cloud risk. The first security failure is usually not a breach but a governance mismatch between a fast-changing infrastructure estate and a security programme that still behaves as if scope is fixed. Cloud teams can provision faster than security can re-test, which makes identity, DNS, and asset inventory drift the real attack surface. Practitioners should treat migration as a continuous governance problem, not a one-time assurance event.
A question worth separating out:
Q: Who is accountable when a cloud migration leaves a takeover path open?
A: Accountability should sit with the owners of the change process, the cloud platform team, and the security team that governs external exposure. If decommissioning, DNS cleanup, and access removal are split across teams, the control gap will usually survive the migration.
👉 Read our full editorial: Cloud migration attack surface is outpacing annual security testing
