TL;DR: Shadow IT keeps appearing when identity is issued before device proof, according to Smallstep. Identity issuance needs admission rules that verify devices before access is granted, or monitoring only records the problem after the fact.
Editorial analysis by NHI Mgmt Group, based on content published by Smallstep: “Shadow IT Exists Because You Don't Control Which Devices Get Identity”.
Key questions
Q: Why do unmanaged devices complicate zero trust access decisions?
A: Because zero trust depends on continuous verification, and unmanaged devices weaken the confidence you can place in the session context.
Q: What are the signs that device validation is happening too late?
A: Look for access that is granted on valid user credentials even when the device is not enrolled, not compliant, or only conditionally checked after login.
Q: What fails when shadow IT controls rely on detection instead of admission?
A: Detection-based controls can show that an unauthorized device or application connected, but they do not stop the access from being issued in the first place.
Practitioner guidance
- Define device proof as a precondition for identity issuance Require device identity checks before tokens are minted, not after sessions begin.
- Separate admission control from continuous monitoring Use monitoring to detect drift, but do not let it substitute for the initial trust decision.
- Extend governance to workloads and SaaS access Apply the same admission rules to workload identities, API tokens, and OAuth grants so unmanaged services cannot authenticate merely because they hold valid credentials.
Bottom line: Shadow IT persists because access is often granted before the organisation confirms that the device, workload, or application should be trusted.
Glossary terms: Device Identity, Admission Controller, Shadow IT, Conditional Access
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Admission is the control boundary, not detection. Shadow IT persists because most identity architectures still grant access first and investigate device legitimacy later. That ordering makes unmanaged access an expected outcome rather than an exception. For identity programmes, the real question is whether the admission decision itself is enforceable, because everything downstream depends on that first trust grant.
A question worth separating out:
Q: How should teams govern workload and application identities that are not known to IT?
A: Treat workload and application access as an admission problem, not just a credential problem. If a service, token, or OAuth grant can authenticate without proving its identity provenance, it can expand shadow IT just as easily as an unmanaged endpoint can.
👉 Read our full editorial: Shadow IT persists when device identity is optional at admission