Your Device Identity Is Probably a Liability
Daniel Michan
Most organizations believe they have device identity because they have certificates.
That belief is usually wrong.The Uncomfortable Truth About Device Identity
The UK National Cyber Security Centre is explicit in its Zero Trust guidance: you must know your user, service, and device identities before you can make trustworthy access decisions. Not some of them. All of them.
You can read the full NCSC principle here.
Most organizations have invested heavily in user identity. MFA, SSO, conditional access policies, directory federation: these are mature, well-understood capabilities. Service identity is catching up, though secrets sprawl remains a real problem.
Device identity is where the architecture breaks.
Not because organizations ignore it. Because they believe it's already handled.
The false equivalence: "We have certificates" does not mean "we have device identity."If those certificates are long-lived, manually issued, stored in exportable software keystores, or renewed through ticket-based processes, you don't have strong device identity. You have cryptographic decoration.
This distinction matters because attackers don't care about your certificate inventory. They care about whether a credential can be copied, moved, and replayed from somewhere else. If it can, your Zero Trust model has a hole you can't see in your logs.
Why This Keeps Happening
Zero Trust assumes breach. It assumes hostile networks. It assumes credentials will be targeted. Under those conditions, authorization decisions can't rely on IP address, VPN presence, or network location. They have to rely on verified, bound identity.
The NCSC makes three requirements explicit:
- Every user must have a unique, verifiable identity
- Every service must have a unique, verifiable identity
- Every device must have a unique, verifiable identity
The first two get budget. The third gets assumptions.
Here is what those assumptions typically look like in practice:
Belief vs. Reality
| What Organizations Believe | What Is Actually True |
|---|---|
| "Our MDM handles device identity." | MDM manages device configuration. It does not issue or enforce cryptographic identity for access decisions. |
| "We have certificates on our devices." | Long-lived, manually managed certificates stored in software keystores can be exported and replayed from any machine. |
| "Our ZTNA solution covers this." | ZTNA evaluates posture signals. Without bound device identity, posture checks can be spoofed or bypassed. |
| "We rotate API keys regularly." | Shared, bearer-style secrets are portable by definition. Rotation reduces window but doesn't bind identity to a device. |
| "Compliance passed the audit." | Audits verify that certificates exist. They rarely verify that credentials are non-exportable, short-lived, or hardware-bound. |
Every one of these beliefs creates a gap between what the architecture claims and what it can actually enforce. Attackers operate in that gap.
What Breaks When Device Identity Is Portable
This is the core failure pattern. When a device credential can be separated from the device it was issued to, the identity is portable. Portable identity is the opposite of Zero Trust.
For CISOs: The Governance Problem
When device credentials are portable, your security architecture lies to you. Authentication logs show valid events. Compliance dashboards show green. But the credential in use may not be on the device it was issued to. The result:
- Stolen certificates are replayed from attacker-controlled infrastructure, and your logs show a legitimate device authenticating.
- Lateral movement becomes invisible because every hop uses a valid, recognized credential.
- Incident response teams chase phantoms: the device looks healthy, the credential looks valid, but the session originated somewhere else entirely.
- Post-breach forensics reveal that "authenticated" did not mean "trustworthy," but the audit trail doesn't distinguish between the two.
For Platform and Infrastructure Teams: The Operational Problem
Portable device credentials create a different kind of pain at the infrastructure layer:
- Shared API keys and long-lived tokens mean any compromised workload can authenticate as any other workload in the same trust domain.
- Certificate renewal is manual or ticket-driven, which means expired credentials cause outages and renewed credentials get stored wherever is convenient.
- No cryptographic binding means containers, VMs, and ephemeral workloads can't prove they are what they claim to be.
- Service mesh mTLS becomes performative: the certificates exist, but they aren't tied to specific workload instances, so compromised pods authenticate freely.
In both cases, the architecture assumes device identity is strong. It isn't. And the failure is silent.
Visualizing the Architecture Gap
The difference between “we have certificates” and “we have strong device identity” is structural. It’s the difference between portable credentials and bound, automated, short-lived identity enforced everywhere.
What Strong Device Identity Actually Requires
Strong device identity isn't a product category. It's a set of properties that must hold simultaneously:
| Property | What It Means in Practice |
|---|---|
| Unique per device | One identity per machine or workload. No shared credentials, no wildcard certs standing in for fleet identity. |
| Cryptographically verifiable | X.509 certificates, not bearer tokens or API keys. The identity can be validated without trusting a central broker at request time. |
| Bound to hardware or workload | Private keys stored in TPMs, secure enclaves, or workload-specific keystores. Credentials cannot be exported or copied. |
| Short-lived | Certificate lifetimes measured in hours, not months. Compromise window shrinks to near-zero when credentials expire automatically. |
| Automatically managed | Issuance, renewal, and revocation happen without human intervention. No tickets, no manual processes, no forgotten renewals. |
| Auditable end-to-end | Full lifecycle visibility: who issued it, when it was used, when it expired, what accessed what. |
If any of these properties are missing, device identity degrades from an enforcement mechanism to a compliance checkbox. That's the gap most organizations are sitting in right now.
How Smallstep Closes the Gap
Smallstep provides automated, certificate-based device and workload identity at scale. Instead of treating device identity as a side effect of PKI, we make it the foundation of Zero Trust enforcement.
What Changes With Smallstep
- Automated X.509 issuance: Every device and workload gets a unique, short-lived certificate issued automatically. No manual enrollment, no shared secrets.
- Certificate lifecycle management: Renewal, rotation, and revocation happen continuously without operational overhead. Expired or compromised credentials don't persist.
- Hardware-bound keys: Private keys stay in TPMs and secure enclaves. Credentials can't be exported, copied, or replayed from another host.
- Infrastructure integration: Device identity plugs directly into Wi-Fi, VPN, ZTNA, Kubernetes, and service-to-service mTLS. Identity becomes the control plane, not an afterthought.
- Centralized visibility: Full audit trail across every certificate, every device, every access decision. No blind spots between issuance and enforcement.
The operational difference: With Smallstep, your access decisions incorporate cryptographic proof of device identity, not just user credentials or posture signals. That's the difference between Zero Trust as a policy and Zero Trust as an architecture.
Traditional PKI gives you certificates. Legacy CLM gives you inventory. Neither gives you bound, automated, short-lived device identity that works across physical machines, cloud workloads, containers, and services simultaneously.
Smallstep does.
Evaluate Your Device Identity Posture
If you're aligning to NCSC Zero Trust guidance, or if your board is asking whether your Zero Trust architecture actually enforces what it claims, start with these questions:
- Lifetime: What is the average certificate lifetime for device credentials in your environment? If the answer is months or years, your blast radius is measured in months or years.
- Binding: Are private keys stored in hardware (TPM, secure enclave) or in software keystores? If software, the credential is exportable. That means it's portable. That means it's not device identity.
- Automation: How are certificates issued and renewed? If the answer involves tickets, manual steps, or "the team handles it," the process doesn't scale and renewal failures cause outages.
- Coverage: Do all machines have unique identities, or are some segments relying on shared secrets, API keys, or long-lived tokens? Partial coverage means partial trust.
- Visibility: Can you trace a device credential from issuance through every access event to expiration? If not, your audit trail has gaps that attackers can exploit and auditors will eventually find.
If you can't answer all five with confidence, your device identity model has structural gaps.That's not a failure of effort. It's a failure of tooling. And it's fixable.
Next Steps
Read the full NCSC Zero Trust principle on identity: NCSC Zero Trust: Know Your Identities
Assess your posture. Use the five questions above as a starting diagnostic. If you find gaps, those gaps are active attack surface. See how automated device identity changes enforcement. Smallstep can show you what certificate-based, hardware-bound, short-lived device identity looks like across your infrastructure, from endpoints to Kubernetes. Request an architecture review. Zero Trust without strong device identity is incomplete. The question is whether you know where the gaps are.Daniel Michan is a marketing architect focused on building durable growth in regulated, high-trust markets. Has scaled go-to-market systems across multiple pre-IPO companies.
