Notifications
Clear all
Topic starter
12/06/2026 10:10 pm
TL;DR: Zero trust reduces implicit trust by requiring verification, device checks, encryption, least privilege, monitoring, and periodic access review, according to Axiad. The governance problem remains the same: programmes that ignore permission creep and access sprawl still leave identity attack surface open.
NHIMG editorial — based on content published by Axiad: How to Implement Zero Trust in Your Business
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Axiad's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on implementing MFA, device verification, and encryption across access paths.
- Practical examples of how to limit access by role and reduce permission creep over time.
- The article's discussion of common zero-trust pitfalls, including implementation cost and user-behaviour change.
- A vendor-oriented walkthrough of single sign-on and passwordless alignment within the same programme.
👉 Read Axiad's blog on implementing zero trust in your business →
Permission creep in zero trust: what identity teams miss?
Explore further
13/06/2026 12:45 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust implementation still fails on permission creep
