Why ADCS Cannot Prove Device Trust Under CMMC Level 2
Daniel Michan
The Dangerous Default Assumption
Most organizations running ADCS believe they have device authentication covered. Under CMMC Level 2, that assumption is often where organizations discover they cannot fully defend their device authentication story. Most will not discover this until the assessment itself, or worse, after an incident forces the question in a context where the answer carries liability.
Certificates are deployed via SCEP, MDM handles enrollment, ADCS issues credentials. The architecture diagram is complete. But CMMC Level 2 does not evaluate architecture diagrams. It evaluates evidence. And the specific evidence it demands, the evidence most ADCS deployments cannot produce, is proof that device authentication controls are actually enforced and that access decisions are backed by verifiable technical controls, not just enrollment assumptions.
NIST SP 800-171 control 3.5.2 requires organizations to authenticate or verify the identities of devices as a prerequisite to allowing access to organizational systems. Under scrutiny, organizations should expect to answer questions like: can you demonstrate, with verifiable evidence, that a specific device was authenticated before it accessed CUI? That the authentication decision was based on a trust anchor you control? That the credential backing that decision was strongly bound to the original hardware?
ADCS, by itself and in its most common deployment patterns, does not answer those questions with high assurance. Not with template hardening. Not with TPM configuration guides applied after the fact. The gap is architectural, not operational. ADCS was designed to issue certificates. CMMC requires demonstration that trust decisions are enforced and evidenced. These are structurally different problems, and closing the distance between them requires a different model, not a better configuration.
The assumption to kill: "We have ADCS and certificates deployed, so device authentication is covered." CMMC does not ask whether you issue certificates. It asks whether you can demonstrate that device trust controls were actually enforced where controlled information is accessed.
Where ADCS and SCEP Break Under CMMC
No Proof of Trust Origin (3.5.2). ADCS issues certificates to devices. But a certificate is not proof that a device was trusted. It is proof that a device requested a certificate and that the CA issued one. Under standard enrollment, the CA does not verify why a device should be trusted. It verifies that the request met template requirements and that the requesting account had enrollment permissions. The certificate proves issuance happened. It does not prove issuance was warranted. No Lifecycle Evidence. ADCS certificates are typically long-lived: one to three years. During that window, the device might change compliance state, move between networks, have its MDM profile removed, or be decommissioned. None of these events automatically revoke or revalidate the certificate. When an assessor asks for evidence of continuous device authentication enforcement, ADCS produces an issuance timestamp and an expiration date. Everything between those two dates becomes an evidentiary gap the organization may struggle to defend under assessment. Credential Portability. In many common ADCS deployments, device private keys are not strongly attested as hardware-bound. They may be software-protected, stored using the Microsoft Software Key Storage Provider, or otherwise insufficiently constrained for high-assurance device identity. If the private key is exportable or not strongly hardware-bound, a credential issued for one device can potentially be replayed or reused from another system. At that point, the certificate does not identify a device. It identifies whoever possesses the key. That is credential authentication, not device authentication, and it does not satisfy 3.5.2. MDM as Proxy for Trust. MDM enrollment and compliance state can be useful control signals, but in most common architectures they are not cryptographically bound to the credential presented at the point of access. The compliance signal lives on the management plane. The authentication event happens on the data plane. These are not synchronized in standard deployments. In many legacy SCEP deployments, enrollment depends on passwords or challenge material that can be replayed or misused if exposed. Even dynamic SCEP improves workflow security more than it proves hardware identity. The MDM may know the device was compliant at enrollment time, but in most common deployments that compliance state is not automatically or cryptographically coupled to the ongoing validity of the certificate at access time.The structural problem: ADCS proves that a certificate was issued. CMMC requires demonstration that a device was trusted. No amount of certificate volume closes the distance between these two claims.
Why ADCS Cannot Be Extended to Meet This Requirement
This is where most organizations stall. They accept the gap, then assume the remediation path runs through ADCS configuration. It does not.
Every common fallback fails for the same reason: it addresses a component without changing the decision architecture. ADCS was not designed as a trust decision system. It was designed as a certificate issuance system. Configuring it harder does not change what it is.
Template hardening does not produce decision evidence. Tighter templates improve issuance hygiene. None of them create a record of why a specific device was trusted. The template governs what the CA will issue. It does not evaluate or record whether the device requesting the certificate should have been trusted in the first place. TPM support does not equal enforced attestation. ADCS supports the Microsoft Platform Crypto Provider, which can generate keys inside a TPM. This is key protection, not key attestation. A key stored in a TPM is protected from export. But without attestation, the CA has no cryptographic proof that the key is actually hardware-bound. Protection is a local property of the device. Attestation is a verifiable claim that a remote party can validate. ADCS does offer TPM key attestation through Endorsement Key verification, but in practice the implementation is operationally complex, inconsistently deployed, and uncommon at enterprise scale. Most organizations deploying ADCS at scale have not configured attestation. Many do not know whether their deployed certificates use hardware-bound keys at all. SCEP constraints are structural, not configurable. You can configure enrollment workflows to prefer TPM-backed key generation, but SCEP itself was not designed as a hardware attestation protocol. It does not inherently give the CA cryptographic proof of hardware provenance or durable evidence that the issued credential should be treated as high-assurance device identity. MDM integration does not equal access-time validation. A device can be non-compliant in MDM and still hold a valid ADCS certificate. A device can be removed from MDM and continue authenticating with its existing certificate until expiration. The management state and the credential state are decoupled. No ADCS configuration change couples them.One clarification, because it will come up in every internal remediation discussion: ADCS was not designed to be a system of record for device trust decisions. That is not a criticism. It is the point. CMMC requires that such a system exist: one that evaluates, persists, and can reconstruct why a device was permitted to connect. Hardening ADCS makes it a better certificate authority. It does not create the trust decision layer that is missing.
A sufficiently engineered Microsoft stack (ADCS combined with enforced TPM attestation, conditional access via Entra ID, network access control with EAP-TLS, and logging tied to device identity) can partially close this gap. The question is whether your organization has implemented all of those, at scale, with evidence generation as a byproduct of operation. In most environments, the engineering effort required to retrofit ADCS into that architecture meets or exceeds the effort of deploying a system that was built for it. And the retrofit produces no evidence until every component is operational. That timeline does not align with assessment schedules already in progress.
The cost of extending the wrong system is not the cost of the project. It is the cost of the project plus the cost of replacing it when the assessment reveals the gap was never closed.
The Real Requirement: Verifiable Device Identity
CMMC Level 2 forces a shift in how device trust must be implemented and evidenced. The requirement is not "issue certificates to devices." The requirement is: demonstrate that device trust decisions are enforced, that only authorized devices authenticate to controlled resources, and that the evidence trail is auditable.
The Device Trust Stack. Four layers. Each depends on the one below it. Missing any layer weakens the chain. Layer 1: Attestation. Proves origin. The key was generated in verified hardware on a specific device. Layer 2: Identity. Binds key to device. The credential is non-exportable and tied to attested hardware. Layer 3: Policy. Decides access. The device was evaluated and permitted at the moment of connection. Layer 4: Evidence. Records the decision. The trust chain is reconstructable under audit.In its standard deployment patterns, ADCS primarily addresses Layer 2, and even there, often without hardware attestation backing the identity by default. Layers 1, 3, and 4 typically require additional systems, custom integration, and operational discipline that most organizations have not implemented end to end.
Any system that satisfies CMMC Level 2 evidence requirements must operate across all four layers. It must verify hardware provenance before issuing a credential, enforce identity at the access point, and log the entire chain, from attestation through access decision, with enough detail to reconstruct any trust decision under audit.
This is the architecture Smallstep was built around. ACME Device Attestation handles Layer 1. The Attestation CA validates hardware provenance and issues a hardware-bound identity at Layer 2. mTLS enforcement evaluates identity at the access point for Layer 3. And the entire chain is logged with the detail required for Layer 4.
Migration Path: ADCS to Smallstep
The migration is not rip-and-replace. It is a layering strategy: introduce hardware-bound identity alongside existing certificate infrastructure, shift workloads progressively, and build the evidence trail that CMMC requires before the assessment, not during it.
Start migration during assessment preparation and you are already too late to build evidence history. CMMC assessors evaluate patterns of compliance, not point-in-time snapshots. A system deployed 30 days before assessment does not produce six months of decision history. That gap cannot be backfilled. There is no retroactive evidence for decisions that were never made.
Phase 1: Parallel Issuance. ADCS remains in place. No existing certificate flows are disrupted. Smallstep is deployed alongside ADCS to begin building a device inventory backed by hardware attestation. Each device's identity is cryptographically chained from the TPM or Secure Enclave through the Attestation CA to the issued certificate. ADCS continues to serve existing workloads without interruption. Evidence produced: every enrolled device has a verifiable chain from hardware to credential. The audit trail begins here. Phase 2: Hardware-Bound Identity Rollout. SCEP enrollment flows are replaced with ACME Device Attestation, the protocol Smallstep co-developed with Google at the IETF. Private keys are generated inside the TPM or Secure Enclave. They cannot be exported. The CA cryptographically verifies hardware binding before issuing. Certificate lifetimes shorten from years to hours or days. Trust is revalidated at each renewal, not assumed from the original enrollment. Shared SCEP challenge passwords are eliminated. Evidence produced: an assessor can trace any credential to a specific hardware module on a specific device. Phase 3: Policy Enforcement via mTLS. Mutual TLS is deployed across workloads, APIs, and internal services that handle CUI. Both client and server present certificates. The server verifies the client certificate was issued by the Smallstep CA and is backed by hardware attestation. Access decisions are made at connection time, not inherited from prior enrollment state. Evidence produced: every access event is tied to a specific device identity, a specific certificate, and a specific hardware attestation. Phase 4: Evidence Generation and Audit Readiness. Audit logs are structured to map directly to CMMC assessment objectives. Evidence packages are pre-assembled for 3.5.1, 3.5.2, 3.5.3, 3.5.4, and 3.13. The evidence exists because the system generates it as a byproduct of operation, not because someone ran a report.Device Identity in Defense Environments
Defense environments do not run homogeneous fleets of managed Windows laptops. They run heterogeneous environments: Windows workstations, Linux servers, embedded controllers, OT systems, air-gapped enclaves, and AI agent workloads accessing sensitive resources. Many operate where real-time posture checks are impractical and MDM reach is limited or nonexistent.
Any identity model that depends on MDM enrollment fails to cover the systems that matter most: Linux workloads in containers that access CUI but never enroll in an MDM. OT systems that lack the OS surface for MDM agents. Edge systems operating with intermittent connectivity. AI agent runtimes that access APIs and handle credentials without human enrollment. CI/CD infrastructure where workload identity must be automated.
In most defense environments, the systems that handle the most sensitive operations, the ones most likely to be targeted and most likely to be examined post-incident, are exactly the systems that fall outside MDM coverage.
Smallstep binds the attestation-to-evidence chain across all of them. Apple devices use the Secure Enclave. Windows and Linux systems with TPM 2.0 use the standard TCG attestation flow. Workloads and containers extend the same trust model through workload identity attestation. A device identity model that covers managed Windows endpoints but leaves Linux systems on weak or self-reported identifiers creates an evidentiary gap that becomes difficult to defend in a CMMC-scoped environment.
The Real Risk
The risk is not that you fail CMMC Level 2.
The risk is that you pass. Partially. With a conditional certification and a 180-day POA&M for the controls you could not fully evidence. You maintain contract eligibility in the short term. Your score clears the 88-point threshold. And then a prime contractor's security review, a post-incident investigation, or a renewal assessment asks the question your system cannot answer:
Why was this device trusted?
Was the credential that authenticated it bound to hardware, or could it have existed on any machine with the right software? Can you prove, right now, that the device that accessed CUI on a specific date was the device you intended to authorize?
ADCS will show that a certificate existed. It will not show that the trust decision was enforced with high assurance. SCEP will show that an enrollment completed. It will not show that the device was the device it claimed to be. MDM will show that a device was managed. It will not show that management status was evaluated at the moment of access.
The organizations best positioned to clear CMMC Level 2 cleanly are the ones building verifiable device identity now. Not next quarter. Not during assessment preparation. Now. The evidence clock does not start when you decide to be compliant. It starts when the system begins generating decisions.
The question is not whether your system issues certificates. It is whether it can defend every trust decision it has already made, including the ones made months ago, under conditions you can no longer reconstruct.
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.
