Shadow IT Exists Because You Don't Control Which Devices Get Identity

Daniel Michan

Follow Smallstep

Shadow IT Exists Because You Don't Control Which Devices Get Identity

The UK's National Cyber Security Centre published guidance on shadow IT. The diagnosis is correct: organizations face real risk from unknown devices, unauthorized applications, and unmanaged cloud resources. The recommended controls (Cloud Access Security Brokers, Unified Endpoint Management, network monitoring) represent industry consensus.

The NCSC guidance stops at detection and mitigation. It assumes the primary challenge is discovering what's already connected, then deciding what to do about it.

That assumption is what creates shadow IT in the first place.

Shadow IT is not a side effect of weak controls. It is the direct result of how most identity systems are designed to work.

Authentication Is a Decision

Authentication is not a neutral act. It is a decision. Every successful authentication is a declaration of trust: your system has determined this entity should be granted access.

Shadow IT is typically framed as a visibility problem. Security teams can't protect what they can't see. The solution: better monitoring, faster detection, more comprehensive inventory.

Standard detection-based controls:

• CASBs monitor cloud application usage
• UEM tracks endpoint inventory
• Network tools flag unauthorized devices

Detection is not primary control. In many implementations, it indicates that admission controls were insufficient.

When you discover unauthorized access after authentication has succeeded, here's what actually happened:

A device authenticated to your systems. Your identity infrastructure validated credentials and issued tokens. The device accessed protected resources: repositories, video calls, file storage. Security tools eventually flagged it as unmanaged.

You didn't prevent the access. You documented it.

Every time an unmanaged device logs in successfully, your system is not being bypassed. It is behaving exactly as designed.

The failure isn't monitoring. You detected it. The failure isn't policy. Your standards prohibit unmanaged devices. The failure is admission. Your identity system granted access based on user authentication, with device verification applied inconsistently or too late in the decision process.

What Shadow IT Actually Proves

Modern identity systems do include device validation capabilities: conditional access policies, MDM enrollment checks, posture validation. But these controls are often:

• Optional rather than mandatory
• Inconsistently enforced across applications
• Bypassed through credential sharing or cached sessions
• Applied after initial authentication, not before identity issuance

Consider three scenarios that happen in organizations with standard security controls:

SSO authenticates the user based on valid credentials. Conditional access may check for device compliance, but if the device was previously trusted or the policy has exceptions, access is granted. The device was never formally enrolled or approved through IT processes.

API token or OAuth grants provide access. The application established trust based on user identity without device-bound verification. Even with CASB monitoring, the connection occurs before the tool is flagged.

In environments where workload identity is not strictly enforced, service credentials authenticate and the workload joins your network using valid identity tokens. Device posture checks designed for endpoints don't apply to workloads the system doesn't know should exist.

The pattern is consistent: if a device can authenticate using valid credentials, most identity systems grant access before comprehensively verifying the device itself.

User authentication is typically strong: multi-factor, risk-based, continuously evaluated. Device authentication is often weaker, inconsistently applied, or easy to satisfy with minimal validation.

That's not a feature gap. It's a design priority that assumes user identity is sufficient. And that assumption enables shadow IT.

Zero Trust Implementations Often Miss the Admission Layer

Zero Trust promised continuous verification: never trust, always verify. Organizations invested in least privilege, microsegmentation, adaptive authentication. Many Zero Trust frameworks do include device posture checks and conditional access.

But most implementations focus on what authenticated entities can access, not which entities should be allowed to authenticate in the first place.

The limitation isn't the Zero Trust model. It's that many implementations verify continuously but grant initial access too permissively.

In admission-based systems, trust is never granted without proof. In detection-based systems, proof is requested after trust is already given, or proof requirements are relaxed to avoid blocking legitimate users.

Zero Trust architectures that rely primarily on post-authentication verification still struggle with shadow IT. They're continuously evaluating entities that should never have received identity tokens to begin with.

The Control Model That Actually Prevents Shadow IT

Device identity enforcement changes where control happens. Instead of monitoring for unauthorized access after authentication succeeds, you enforce requirements before identity is issued.

This is not an incremental improvement to existing controls. It's a different enforcement model:

This requires:

• Hardware-bound credentials that prove device identity
• Issuance policy that encodes admission requirements
• Automated lifecycle management that maintains compliance

When implemented correctly, shadow IT cannot authenticate. A personal laptop has no path to device certificates unless explicitly provisioned. Unauthorized applications cannot present device-bound credentials. Unknown workloads cannot establish trust without meeting admission policy.

The enforcement happens at identity issuance, before authentication grants access to protected resources.

Even strong admission control must be complemented by detection and continuous verification, since identity can still be abused after issuance. But when admission is weak, detection becomes the primary control. Not by design, but by necessity.

Why Existing Device Controls Fall Short

Organizations do have device validation capabilities. The question is when and how consistently they're enforced.

Conditional access policies can block non-compliant devices, but they typically evaluate compliance after accepting authentication. MDM enrollment can be required, but exceptions exist for contractors, partners, or emergency access. Posture checks can verify device state, but they often run after the device has network access.

These are important controls. But they operate within a model that grants provisional access first, then evaluates whether that access should continue.

Shadow IT persists not because these controls don't exist, but because identity systems are designed to be permissive by default. Because denying legitimate access is immediately visible, while allowing unauthorized access is often invisible.

That tradeoff made sense when organizations controlled their perimeter. It doesn't scale to cloud environments where devices, users, and applications span multiple security domains.

What Actually Has to Change

Shadow IT is not purely a visibility problem. It's a consequence of how identity is issued.

Organizations don't lack device validation capabilities. They lack enforcement at the admission layer: the decision point where identity is granted or denied.

As long as identity can be issued based on user credentials alone, without mandatory device verification, shadow IT is not an anomaly. It is an expected outcome.

Device identity enforcement makes admission an architectural requirement:

• Zero Trust needs device identity as foundation. Continuous verification should validate what was correctly trusted initially, not compensate for permissive issuance.
• Workload security requires device-bound credentials to prevent unknown services from authenticating.
• API security makes application tokens insufficient without device identity validation.
• Compliance shifts from "did we detect violations" to "did we prevent unauthorized admission."

The NCSC guidance identifies real risks and recommends proven controls. But detection-focused approaches, even sophisticated ones, operate within a model that grants access before comprehensively verifying devices.

That model is what makes shadow IT persistent.

Shadow IT doesn't exist only because you can't see it. Shadow IT exists because most identity systems allow it by default and detect it as an exception.

Until identity issuance becomes a controlled, enforceable decision (until device verification is mandatory rather than conditional), shadow IT will continue. Not as an anomaly. As the default operating condition of systems that prioritize user convenience over admission control.

No system can rely solely on prevention. Detection and response remain essential. But when admission is weak, detection becomes the primary control. Not by design, but by necessity.

Controlling identity issuance is not a feature. It is an architectural decision. Organizations that enforce device identity at the admission layer won't just manage shadow IT better. They'll remove the structural condition that makes it inevitable.

The question isn't whether your organization has shadow IT. The question is whether your identity architecture is designed to prevent unauthorized devices from authenticating, or to detect them after they already have.