Notifications
Clear all
Topic starter
08/06/2026 4:04 pm
TL;DR: Zero trust means nothing is automatically trusted, yet implementation still fails when organisations overextend access, rely on perimeter-era assumptions, and leave permission creep unchecked, according to Axiad's guidance. The real test is whether identity, device posture, and least privilege are enforced continuously across human and non-human access paths.
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.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams implement zero trust without creating more user friction?
A: Start with the highest-risk access paths and make verification proportional to sensitivity.
Q: Why do service accounts and API keys complicate zero trust?
A: Because they do not behave like human users, yet they often carry persistent access into cloud and application environments.
Q: What breaks when permission creep is not controlled in a zero-trust programme?
A: The model stops being dynamic and becomes a new wrapper for old standing access.
Practitioner guidance
- Map every trust decision to a live control owner Document who owns MFA, device verification, access review, and encryption decisions for each identity class.
- Remove permission creep before recertification starts to lag Compare current entitlements against job function, workload purpose, or approved use case, then revoke access that no longer has a clear operational need.
- Extend zero-trust checks to non-human identities Apply the same verification discipline to API keys, service accounts, and workload credentials that you use for people.
What's in the full article
Axiad's full blog covers the implementation detail this post intentionally leaves for the source:
- Step-by-step guidance for MFA deployment across user populations and access tiers
- Practical examples of device verification, VPN use, and approved-device controls
- Access review and permission creep checkpoints for ongoing zero-trust operations
- Encryption and role-based access control guidance for reducing exposed data paths
👉 Read Axiad's guide on implementing zero trust in business environments →
Zero trust permission creep: what IAM teams need to fix first?
Explore further
08/06/2026 5:29 pm
Permission creep is the clearest zero-trust failure mode because it turns a dynamic model back into standing privilege. The article correctly treats access review as part of the answer, but the underlying problem is governance drift, not a missing feature. Once access accumulates faster than it is recertified, zero trust becomes a slogan over a legacy entitlement model. The practitioner conclusion is simple: zero trust must be measured by entitlement decay, not policy language.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, which is why access minimisation cannot stop at the human login boundary.
A question worth separating out:
Q: Who is accountable when zero-trust controls fail to reduce access over time?
A: Accountability sits with the identity, access, and application owners who define trust rules and with the governance function that recertifies them. If elevated access persists unchecked, the failure is usually in ownership, review cadence, or enforcement rather than in a single technical control.
👉 Read our full editorial: Zero trust implementation is still undermined by permission creep
