They can create a large blast radius that turns one compromised control point into organisation-wide impact. If an attacker reaches deployment permissions, they may be able to deploy malicious infrastructure, modify StackSets, or propagate changes into connected accounts. In practice, broad deployment privileges can convert routine infrastructure automation into a path for lateral movement and account takeover.
Why overly broad CDK bootstrap and CloudFormation execution roles create systemic deployment risk
These roles are not just “deployment permissions.” They define what infrastructure code can create, change, and delegate on your behalf. If they are overbroad, the trust boundary moves from a controlled pipeline into a high-privilege path that can affect many accounts, stacks, and dependent services at once.
That matters because deployment roles often sit at the centre of repeated automation. A single compromised role can be reused across releases, pipelines, and environments, so the damage is not limited to one stack change. The Cloud Workload Identity Guide is useful here because it explains how temporary deployment credentials, federation, and role scoping should be bounded so automation does not become standing privilege.
In practice, the blast radius is determined less by CloudFormation itself than by what the execution role is allowed to do once a template starts running. If that role can touch broad IAM, networking, cross-account resources, or StackSets, then template execution can become a control plane for environment-wide change rather than a narrowly scoped infrastructure operation.
How broad roles turn one compromise into lateral movement
When bootstrap or execution roles are too permissive, an attacker who reaches the pipeline, the deployment agent, or the role assumption path may be able to use legitimate automation to stage persistence, spread changes to connected accounts, or weaken guardrails. That is especially dangerous because the activity can look like ordinary infrastructure delivery rather than direct interactive abuse.
One common failure mode is delegated authority that was intended for deployment convenience becoming a path to privilege escalation. A role that can create or update IAM resources, pass service roles, or modify stack targets may let an attacker rewire future deployments after the initial compromise is contained. For broader threat-path analysis, MITRE ATT&CK Enterprise Matrix helps frame the sequence as credential access, privilege escalation, and lateral movement rather than a one-off misconfiguration.
Another failure mode is cross-account propagation. If execution permissions extend into shared accounts, StackSets, or centrally managed environments, a single bad template or malicious update can spread the impact well beyond the first account that was reached.
What good scoping looks like in practice
Broad roles should be narrowed to the smallest action set that can still perform the deployment task. The important judgment is not whether the role can deploy, but whether it can only deploy the exact resources, in the exact accounts, with the exact conditions required for that workload.
That usually means separating bootstrap permissions from runtime deployment permissions, constraining pass-role and assume-role paths, and avoiding wildcard access to IAM, KMS, networking, and organization-wide targets unless there is a documented reason. When the deployment path depends on cloud IAM, the Cloud Workload Identity Guide is a practical reference for thinking about role boundaries, federation, and temporary access rather than long-lived broad trust.
The stronger control pattern is to treat deployment roles as privileged infrastructure identities, not generic build credentials. That means reviewing them with the same care you would apply to an admin path: explicit trust policy, narrow resource scope, short-lived access where possible, and clear separation between creating infrastructure and administering identity or security controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broad deployment roles are an excessive-privilege problem. |
| AC-5 — Separation of Duties | Bootstrap and execution power should not collapse into one broad control point. | |
| IA-9 — Service Identification and Authentication | CloudFormation and related automation rely on trusted service and workload identities. | |
| Recommendation — Restrict deployment roles to the minimum actions and resources needed. Split provisioning, approval, and execution duties across distinct roles. Authenticate deployment services with tightly scoped, verifiable workload identities. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Deployment roles are non-human identities that can be overprivileged. |
| NHI-08 — Environment Isolation | Broad roles can spread changes across connected accounts and environments. | |
| Recommendation — Reduce non-human deployment roles to the narrowest viable permissions. Isolate deployment permissions by environment and account boundary. | ||
Practitioner Guidance
What to verify: Confirm whether the execution role can create or modify IAM roles, attach policies, pass service roles, or update StackSets across accounts. If it can, assume the deployment path itself is privileged and review it as an escalation surface, not just a delivery tool.
Decision rule: If a role can affect more than one environment, account, or trust boundary, require explicit scoping justification before approving it. If the role is used by automated deployment, treat every additional permission as an increase in blast radius, not as harmless flexibility.
What good looks like: A compromised deployment step should be able to alter only the narrow stack or resource set it was designed for, with no ability to rewire future access, broaden trust, or propagate changes into adjacent accounts.
Practitioner takeaway: The real control objective is not to stop infrastructure as code, but to make sure the identities that execute it cannot become hidden administrators of the whole cloud estate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
