Notifications
Clear all
Topic starter
12/06/2026 12:28 am
TL;DR: Many organisations say they have implemented Zero Trust, but JumpCloud argues that partial coverage across IAM, device trust, network access, PAM, and visibility leaves material gaps. The deeper issue is not whether Zero Trust is adopted, but whether it is enforced consistently across the full access surface.
NHIMG editorial — based on content published by JumpCloud: Where Zero Trust Falls Short and What You Can Do About It
Questions worth separating out
Q: How should security teams implement Zero Trust without creating too many exceptions?
A: Start by mapping where the current programme still trusts users, devices, or services by default.
Q: Why do verified users on unmanaged devices still create serious risk?
A: A verified user on an unmanaged device can still expose the organisation to malware, session theft, or data loss because identity assurance does not guarantee endpoint integrity.
Q: What do teams get wrong about Zero Trust and privileged access?
A: They often treat PAM as a separate admin control instead of a central Zero Trust function.
Practitioner guidance
- Expand MFA beyond admin accounts Enforce MFA across all access points, including routine user access and remote workflows, so the control is not reserved for the highest-risk accounts only.
- Tie access to device posture Require OS version, patch status, encryption, and MDM enrollment checks before sensitive applications or data can be reached from any endpoint.
- Replace broad internal access with app-level policy Move away from network-wide trust and grant only the specific application or service access needed for the session, which reduces lateral movement opportunities.
What's in the full article
JumpCloud's full blog post covers the operational detail this post intentionally leaves for the source:
- A phased Zero Trust roadmap that sequences IAM, device trust, PAM, and monitoring into an implementable programme.
- Specific control examples for conditional access, endpoint posture checks, and privilege revocation across common environments.
- Practical guidance on reducing broad network access and replacing it with application-level enforcement.
- Implementation context for organisations trying to move beyond high-risk-user-only coverage.
👉 Read JumpCloud's analysis of where Zero Trust programs fall short →
Zero Trust coverage gaps: what IAM teams are missing?
Explore further
12/06/2026 9:42 am
Surface-level Zero Trust is governance theatre, not risk reduction. The model only changes security posture when identity, device posture, network access, privilege, and monitoring are enforced as a single operating system. If any pillar is only applied to high-risk users or a subset of services, attackers still find broad paths through the remaining trusted surface. Practitioners should measure coverage across the whole access path, not the presence of a Zero Trust label.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when Zero Trust only covers part of the environment?
A: Accountability sits with the security and identity owners who accepted exceptions without defining how risk would be contained, monitored, and reviewed. Framework alignment is strongest when access governance, telemetry, and privileged controls are managed as one programme rather than disconnected tools.
👉 Read our full editorial: Zero Trust falls short when coverage stops at high-risk users
