Your organization cannot meet the new NSA Zero Trust Implementation Guidelines. Here's how to do it.

Daniel Michan

Follow Smallstep

In January 2026, the National Security Agency released a series of Zero Trust Implementation Guidelines (ZIGs), including a Primer, a Discovery Phase, and Phase One and Phase Two implementation documents. Together, Phase One and Phase Two organize 77 activities across 64 capabilities and outline what it takes to reach "Target-level" zero trust maturity by the Department of War's (formerly Department of Defense) FY 2027 deadline.

The guidance is thorough. It covers users, devices, applications, networks, data, analytics, and orchestration. It draws on NIST SP 800-207, the CISA Zero Trust Maturity Model, and the DoW Zero Trust Reference Architecture. And it reinforces a principle that the security community has been circling for years: never trust, always verify, and assume breach.

But buried in the architecture is an assumption that most organizations still cannot meet.

Zero trust architectures assume that devices can present strong, cryptographically verifiable identities. In practice, most enterprise environments still rely on identifiers and credentials that can be copied, replayed, or spoofed. The result is a security model that demands device verification but rarely implements it.

Zero trust requires device identity. Most enterprises still have device identifiers.

The NSA's framework treats device identity as a foundational pillar. Continuous authentication, as described in the guidance, applies not just to users but to every device and application requesting access. The problem is that most enterprises have no reliable way to prove that a device is what it claims to be.

User Identity Is Solved. Device Identity Is Not.

Most organizations have invested heavily in user identity. Single sign-on, multi-factor authentication, identity providers, and conditional access policies are standard. These systems answer the question: who is this person?

But zero trust requires a second question: what device are they using, and can we trust it?

This is where most architectures fall apart. The signals organizations rely on today to identify devices are weak, indirect, and often trivially spoofed.

MAC addresses can be changed in seconds. MDM enrollment confirms that a management profile was installed on some device at some point, but it does not cryptographically bind that device to an identity. Passwords and shared secrets can be intercepted, replayed, or exfiltrated by attackers. And SCEP, the Simple Certificate Enrollment Protocol that has been the default for enterprise device enrollment for over two decades, was designed for networking gear and has no built-in mechanism to verify that a certificate request originates from a specific physical device.

None of these approaches answer the question zero trust ultimately demands: is this the actual device we trust, and is the credential bound to its hardware?

This gap already exists at scale. Many "device trust" systems still rely on credentials that can be exported or replayed on another machine. If the credential can move between devices, the system is not verifying the device. It is enforcing identity at the wrong layer.

Why Legacy Device Identity Falls Short

The core issue is portability. Traditional device credentials, whether they are passwords, shared secrets, or SCEP-issued certificates, are portable. They can be copied to another device, exfiltrated by malware, or intercepted in transit. Once an attacker has the credential, the device it originally came from is irrelevant.

Stolen credentials and token replay remain among the most common breach vectors. If a device credential can exist independently of the device it was issued to, it provides no real device identity. It is just another password with extra steps.

SCEP compounds this problem. It relies on a shared challenge password to authorize certificate enrollment. Any device that knows the password can request a certificate. There is no attestation, no hardware binding, and no way for the certificate authority to verify that the request came from a device on the organization's trusted inventory.

For a zero trust architecture that demands continuous verification of every device, these approaches are structurally insufficient.

Hardware-Attested Device Identity

Modern devices already contain the hardware needed to solve this problem. Trusted Platform Modules on Windows and Linux, the Secure Enclave on Apple devices, and hardware-backed keystores on Android can all generate private keys that never leave the device. These keys are created inside the secure hardware, used for cryptographic operations on the device, and cannot be exported, copied, or extracted by software.

Hardware attestation takes this a step further. Through attestation, a device can produce a cryptographic proof, signed by the hardware manufacturer's root of trust, that a specific key was generated inside a specific device's secure hardware. This proof can include the device's serial number, manufacturer, model, and firmware state. It answers not just "does this device have a key?" but "was this key generated on this specific trusted device, and is it still protected by hardware?"

This is the level of assurance that the NSA's zero trust framework implicitly requires. Continuous device authentication means nothing if the device credential can be separated from the device. In other words, zero trust requires device identity that cannot be separated from the device itself.

ACME Device Attestation: The Emerging Standard

The industry is converging on a standard for this model. ACME Device Attestation (ACME-DA), currently progressing through the IETF, extends the ACME protocol (the same protocol that powers Let's Encrypt) with a new challenge type: device-attest-01. This challenge requires the client to present a hardware attestation statement proving that the certificate key is bound to a specific device's secure hardware.

ACME Device Attestation replaces SCEP's shared-password model with hardware-backed cryptographic verification. The certificate authority no longer has to trust that the right device is making the request. It can verify it. The result is a certificate that is bound to a specific device, backed by hardware that prevents key export, and issued through an automated protocol that supports modern certificate lifecycle management.

Smallstep co-developed the ACME Device Attestation standard with Google through the IETF. Our platform implements this model natively across macOS, iOS, Windows, Android, and Linux, enabling organizations to issue hardware-bound certificates to every device in their fleet without manual enrollment or shared secrets.

What This Looks Like in Practice

With hardware-attested device identity in place, an organization maintains a trusted device inventory tied to hardware identifiers. When a new device is issued to an employee, it enrolls automatically using its secure hardware to attest its identity to the organization's certificate authority. The issued certificate is bound to that device's TPM or Secure Enclave. It cannot be copied to another machine.

That certificate then authenticates the device across every access layer: Wi-Fi, VPN, SaaS applications, SSH, and internal services. Conditional access policies can enforce that only attested, hardware-verified devices reach sensitive resources. If a device is compromised or decommissioned, its certificate is revoked, and no other device can reuse its credential.

This model directly addresses what the NSA's zero trust guidelines demand. Device authentication becomes continuous, cryptographic, and hardware-rooted, not a one-time MDM check or a shared password.

Zero Trust Requires Identity Everywhere

The NSA's Zero Trust Implementation Guidelines make clear that perimeter-based security is no longer viable. Continuous verification of users, devices, and workloads is the operating model, not a product you deploy once.

Most organizations have the user identity piece. Workload identity is maturing. Device identity remains the gap.

Cryptographically verified, hardware-attested device identity is not an advanced capability reserved for nation-state defense. It is becoming a baseline security control. Open standards support it. The hardware organizations already own can enforce it. The protocol to automate it exists.

The NSA's zero trust guidance does not explicitly prescribe a solution. But it does make one thing clear: architectures built on portable credentials and weak device identity signals will not meet the bar for continuous verification. The gap is structural, and the tools to close it are no longer theoretical.