Zero trust implementation still fails on permission creep

At a glance

What this is: An Axiad blog on implementing zero trust that argues access must be continuously verified, limited, and reviewed to prevent permission creep.

Why it matters: It matters because zero trust only holds when IAM, NHI, and human access controls actually enforce least privilege and ongoing verification across changing environments.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Axiad's blog on implementing zero trust in your business

Context

Zero trust is a security model built on one simple premise: access is never assumed, even after a user or device is already inside the network. In practice, that makes identity the control plane, because every request has to be authenticated, authorised, and continually re-evaluated against context.

The weakness in many programmes is not the concept itself but the governance gap behind it. If access grows through permission creep, if device trust is treated as static, or if service accounts and other NHIs sit outside the same review discipline as humans, zero trust becomes a slogan rather than an operating model.

Key questions

Q: How should security teams implement zero trust without creating excessive friction?

A: Start by protecting only the highest-risk access paths, then expand the model once authentication, device checks, and policy decisions are reliable. Keep the user experience manageable by limiting prompts to meaningful risk changes, not every action. The goal is not more friction. It is better identity assurance and smaller blast radius.

Q: Why do service accounts complicate zero trust programmes?

A: Service accounts often have standing access, weak ownership, and long-lived credentials, which makes them hard to evaluate with the same controls used for people. If they are excluded from identity review, zero trust becomes uneven. Machine identities must be governed with the same least-privilege and lifecycle discipline as user accounts.

Q: What do teams get wrong about permission creep in zero trust?

A: They treat it as a periodic audit issue instead of a live security exposure. By the time access review finds excess privilege, the identity may already have been used in a lateral movement path. Permission creep must be reduced continuously, with clear ownership for every role and entitlement.

Q: Who is accountable when zero trust fails because access was never removed?

A: Accountability should sit with the identity and application owners who approved or inherited the access, not just the security team. Zero trust depends on lifecycle hygiene, so offboarding, recertification, and privilege removal need named owners. If no one owns stale access, the control will drift out of policy.

Technical breakdown

Why zero trust depends on identity verification at every request

Zero trust replaces perimeter trust with continuous verification. That means authentication, device posture, and policy checks have to happen at the moment of access, not just at login. The model assumes that a trusted network location does not equal trusted identity, which is why MFA, device validation, encryption, and contextual authorisation are all part of the same control stack. Without those checks, a single compromised credential can move too far too quickly.

Practical implication: make every privileged access path depend on live identity and device signals, not on network location alone.

How permission creep undermines least privilege

Permission creep is the gradual accumulation of access that no longer matches current job need. In zero trust, that is more than an administrative issue, because excess access expands blast radius and weakens the value of continuous verification. The article correctly ties this to periodic access review, but the deeper point is that least privilege decays unless entitlement scope is actively managed across people, devices, and machine identities.

Practical implication: review entitlements regularly and remove stale access before it becomes an attack path.

Why device trust must be treated as a separate control layer

Device verification is not the same as user authentication. A user may prove who they are while the device remains unmanaged, compromised, or out of policy. Zero trust therefore requires a second decision layer for device posture, often through VPN enforcement, endpoint agents, or approved-device controls. For NHI programmes, the same principle applies to workload and service identities, where the hosting environment becomes part of the trust decision.

Practical implication: separate user assurance from device or workload assurance so one weak layer cannot validate the other.

NHI Mgmt Group analysis

Zero trust fails when permission creep is treated as an administrative issue instead of an identity risk. The article correctly identifies access sprawl as a common pitfall, but the deeper governance problem is that accumulated privilege turns verification into theatre. Once entitlements drift beyond current need, continuous authentication does not meaningfully reduce blast radius. Practitioners should treat permission creep as a control failure, not a housekeeping task.

Permission creep is a named identity blast-radius problem, not just excess access. The article focuses on periodic review, but the more useful framing is that access review is only effective when entitlement scope is already bounded. Without that boundary, review cycles become retrospective rather than preventive. Practitioners should evaluate whether their zero-trust programme can actually constrain accumulated privilege across human, NHI, and device identities.

Zero trust becomes brittle when service accounts and other NHIs sit outside the same governance loop as users. The article speaks mainly to human authentication and device controls, but modern environments depend on machine identities that often carry broader and longer-lived access. That is where zero trust either extends into real identity governance or stops at the perimeter by another name. Practitioners should extend the same verification and access-limiting discipline to NHIs.

Authentication alone is not zero trust if authorisation never changes with context. The article ties together MFA, encryption, and monitoring, but those controls only work when policy decisions are continuously recalculated against risk, device state, and entitlement scope. Static approval models cannot deliver a true zero-trust posture. Practitioners should test whether their authorisation layer can respond dynamically when conditions change.

Zero trust is now an identity lifecycle problem as much as an access-control problem. The article’s warning about changing user behaviour points to a broader reality: onboarding, access changes, and offboarding must all feed the same trust model or stale access will accumulate. That applies across human IAM, NHI lifecycle governance, and privileged access management. Practitioners should align lifecycle controls with zero-trust policy rather than treating them as separate programmes.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For a deeper breach-focused view, 52 NHI Breaches Analysis shows how identity failures translate into real compromise patterns.

What this signals

Permission creep is the quiet failure mode in many zero-trust programmes. If entitlement scope keeps expanding while review cycles stay static, the model becomes harder to trust with each quarter. Teams should watch for roles that persist after job change, inherited admin rights, and service accounts that no longer have an accountable owner.

The practical signal is whether identity governance can shrink access faster than the environment grows. If your programme cannot remove stale privilege across users and NHIs at the same speed that new access is created, zero trust will remain partial. That is a lifecycle problem, not just a policy design problem.

A mature programme will connect access review, offboarding, and policy enforcement to the same control layer. That is the difference between a control framework that describes trust and one that actually reduces exposure.

For practitioners

• Map every trust decision to a specific identity and device signal Require MFA, device posture, and policy evaluation at the point of access for sensitive systems. Avoid granting trust based only on network location or a successful initial login, because those signals do not age well once a session begins.
• Run an entitlement review focused on permission creep Check whether users and service accounts still need the access they hold today, not the access they needed at onboarding. Remove stale roles, unused API permissions, and standing privilege that no longer has a current business owner.
• Separate human and machine trust workflows Apply the same zero-trust discipline to service accounts, API keys, and workload identities that you use for users. Different identity types need different evidence, but they should not be exempt from least privilege or periodic review.
• Test whether authorisation changes with context Validate that access decisions can tighten when device posture degrades, risk rises, or a sensitive action is attempted. If your policy cannot adapt after login, the programme is enforcing authentication, not zero trust.
• Align lifecycle controls with zero-trust policy Make offboarding, access change, and recertification feed the same policy engine that governs live access. Zero trust fails when old entitlements remain valid long after the identity or its context has changed.

Key takeaways

• Zero trust only works when access is continuously re-verified, not merely checked at login.
• Permission creep is a direct identity-risk problem because accumulated privilege expands blast radius and weakens least privilege.
• Human, device, and machine identities all need the same lifecycle discipline if zero trust is to function as a real control model.

Key terms

• Zero Trust: A security model that assumes no user, device, or workload is trustworthy by default. Access is granted only after verification and is re-evaluated as context changes. In identity programmes, zero trust becomes a living authorisation model rather than a one-time login decision.
• Permission Creep: The gradual accumulation of access that an identity no longer needs. It happens when roles, entitlements, and special access are not removed as jobs, systems, or responsibilities change. In zero trust, it directly increases blast radius and weakens least privilege.
• Non-Human Identity: An identity used by software rather than a person, such as a service account, API key, token, or certificate. These identities often have long-lived access and weak ownership, so they need lifecycle controls, rotation, and review just like human accounts, but with different operating patterns.
• Device Posture: The security state of an endpoint, workload host, or managed device at the moment access is requested. Posture can include patch level, policy compliance, and the presence of security controls. Zero trust depends on this signal because user identity alone does not prove a safe device.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Axiad: How to Implement Zero Trust in Your Business. Read the original.