Read Time:
6
Minutes
Agile & Delivery Practices
May 1, 2026
Avoiding Privilege Creep: Designing Access Control for Real Delivery Environments
At Ntegra, a leading digital engineering practice within the Actica Group, we help organisations overcome the common challenges of scaling early success across large-scale, digital transformation programmes.
To prevent privilege creep in Defence and CNI, organisations must move beyond transactional IAM toward a governance-led model. This is achieved by applying least privilege through automated, tiered environments (Sandbox, Dev, Prod) and integrating Joiners, Movers, Leavers (JML) workflows into the technical platform to ensure defensible compliance with JSP 440, 453 and NIST800-53.
In this ongoing series, Defended Solutions and Ntegra explore the links between secure design and real-world delivery environments. Written by Daniel Mulliss, with contributions from Ntegra.
In Defence and CNI, identity and access management are often treated as operational "tickets" to be issued once a platform is ready. This approach treats security as a final checkbox rather than a foundational design requirement.
Privilege creep, the unmanaged accumulation of access rights, is rarely caused by delivery teams "cutting corners." Instead, it is a governance failure that begins before delivery starts. When governance models are designed only for established, static environments, they fail to account for the dynamic nature of modern cloud delivery.
The core issue is that governance often stops at the edge of the production environment. For true security, least privilege must be applied across every environment, from the first sandbox to the final live platform. If the governance model doesn’t reflect how agile work actually happens, where developers need to promote code and rotate secrets at speed, delivery teams are forced to seek excessive permissions just to avoid being blocked.
The Friction Between Static Governance and Active Delivery
Traditional Identity and Access Management (IAM) models are built on a transactional "request and grant" basis. While this works for static office roles, it creates two distinct forms of risk in continuous delivery environments:
The Speed Gap ("Vertical" Privilege Creep): Agile delivery moves at a pace that manual governance cannot match. When the "Just-in-Time" (JIT) process requires a human in the middle of every transaction, it creates a bottleneck. To maintain velocity, teams seek permanent, "Administrator-level" access.
The Ownership Gap ("Horizontal" Privilege Creep): The JML process is often an HR-led function divorced from the technical platform. This creates "drift" where people move projects or leave the organisation, but their elevated privileges persist. Without a technical link between HR and platform access, you end up with "orphaned identities."
2. Delivery as the Stress Test
Delivery requires speed and continuity. When governance is too slow, teams find "workarounds" to stay agile. As explored in our guide on Digital Delivery Programmes Failing to Scale, this friction reveals three common "compensating controls":
- Standing Privileges as a Buffer: Holding "Admin" access because manual JIT is too cumbersome.
- Over-permissioned Pipelines: Automated tools given "Full Access" because granular permissions weren't defined in time.
- Shared Identities: Using service accounts to bypass delays, making actions non-attributable.
3. Designing for Control: The Tiered Environment Model
Control comes from design, not restriction. A clear example of this can be drawn from our work in high-stakes sectors like Air Traffic Control, where the transition between development and live operations is handled through a strictly tiered model:
Ntegra's Perspective:
At Ntegra, we see Infrastructure as Code as the natural complement to a tiered environment strategy and what transforms a well-designed governance model into something repeatable, auditable, and scalable. When each tier is defined in code rather than configured manually, the architecture itself becomes the guardrail: environments are provisioned consistently, configuration drift is eliminated, and security policies are version-controlled and reviewable rather than buried in a runbook. In high-stakes sectors like Air Traffic Control, that consistency is foundational. It also shifts accountability from the individual to the system. When Production is provisioned by the same code that has been tested, reviewed and approved, confidence scales without depending on any single person.
4. What Good Looks Like: Governed and Delivery-Aligned
In a well-governed environment, security is a measurable output of the platform.
The Governance Signals (The "Defensible" Layer)
Explicit Ownership: A defined RACI for access decisions across all environments.
Automated JML: Technical workflows ensure access is revoked the moment a status changes.
Audit-Ready Visibility: The ability to evidence who has access and why via automated logs rather than spreadsheets.
The Delivery Signals (The "Velocity" Layer)
Low Friction: Dev teams build within guardrails rather than fighting them.
Minimal Manual Privilege: Changes are handled through automated pipelines where privilege is assigned to the process, not the person.
5. Risk: Where This Becomes Organisational Exposure
In Defence and CNI, unmanaged access leads to a Loss of Assurance. Organisations face a significant Compliance Gap:
Defence: Failing to meet "need-to-know" mandates of JSP440/453, stalling project Accreditation.
CNI: Inability to map against NIST 800-53 controls, specifically AccountManagement (AC-2) and Least Privilege (AC-6).
CIO Diagnostic: Can You Defend Your Position?
To determine if your access model is built for modern delivery, ask these three questions:
- Do we have an explicit, documented RACI for who owns access decisions across every environment?
- Can we evidence, with an automated audit trail, exactly why every individual holds their current permissions?
- Are our teams relying on standing privileges because our Just-in-Time (JIT) processes are too slow?
If the answer is "no," the issue isn't enforcement. It is design.
Is your identity model built for 2026 security resets?
Ntegra works with government and public sector organisations to deliver digital engineering solutions that are secure by design, built for scale and grounded in real governance practice.
Find out how we can help.
Frequently Asked Questions
How does JSP 440 and JSP 453 impact Identity and Access Management (IAM)?
JSP 440 (Manual of Security) and JSP 453 (Information Systems Security) mandate strict least-privilege and attribution controls. To be compliant, organisations must provide an audit trail for every privileged action. A governed IAM model ensures that access is not just granted but is also time-bound and justified, which is essential for achieving Authority to Operate (ATO).
Why is the JML process critical for NIST 800-53 compliance?
The Joiners, Movers, Leavers (JML) process is central to the NIST 800-53 Account Management (AC-2) control. Without a technical link between HR systems and the cloud platform, "orphaned identities" (former staff or contractors with active access) remain in the system. Automating JML ensures that access is revoked instantly upon a change in status, maintaining a defensible security posture.
What is Just-in-Time (JIT) access in a Secure-by-Design framework?
Just-in-Time (JIT) access provides users with elevated permissions only when needed and for a limited duration. By moving away from "Standing Privileges," organisations reduce the attack surface. In a Secure-by-Design model, JIT is automated within the platform to ensure security does not slow down delivery velocity.
How do tiered environments (Sandbox, Dev, Prod) prevent privilege creep?
By siloing environments, organisations can apply different governance levels based on risk. Sandboxes allow for rapid innovation with lower friction, while production remains locked down with absolute auditability. This tiered approach prevents "high-side" permissions from being used for"low-side" development tasks, containing the risk of privilege drift.
What role does Infrastructure as Code (IaC) play in access governance?
Infrastructure as Code (IaC) allows access policies to be baked into the environment deployment. Instead of manual configuration, permissions are defined in code, reviewed via pull requests, and deployed automatically. This ensures that the environment is "Governed by Design" and provides an immutable record of who granted what access and when.
