Register for part 2 of our Device Identity Webinar Series!

Verify device identity before granting access to CUI systems

For defense contractors and the organizations that handle CUI under NIST SP 800-171. Smallstep issues device certificates under inventory and enrollment policy, with hardware-backed keys where supported; your Wi-Fi, VPN, and application integrations enforce them. Correlate certificate records with enforcement-point logs to support access reviews and assessments.

Get a demo
background gradientbackground texture

The device identity challenge for defense contractors

The obligation did not pause

CMMC Phase 2 is suspended with no restart date. DFARS 7012, NIST 800-171 self-assessment, and the SPRS score remain conditions of award, and an overstated score can create False Claims Act exposure in certain circumstances.

Device authentication answered with passwords

800-171 asks you to identify and authenticate devices, not only users. Many environments still answer it with shared Wi-Fi passwords or SCEP certificates issued on a static challenge.

Hosting constraints

Your authorized boundary and approved architecture decide where a certificate authority can run. A SaaS-only control plane is a non-starter for some programs.

Cryptography requirements

800-171 requires FIPS-validated cryptography where it protects CUI confidentiality. Which modules apply, and their validation status, depends on the deployment architecture.

Linux, labs, and field hardware

Research computing, manufacturing floors, and deployed systems are not all MDM-managed laptops. Device identity has to cover them too.

Evidence, not assertion

Assessors and auditors want to see which devices hold credentials, how they got them, and what happened when one left.

Authenticate the device, not only the user

Your identity provider keeps authenticating people. Smallstep establishes device identity with hardware-backed, attested keys where the platform supports them, then issues application certificates under inventory and enrollment policy. Your Wi-Fi, VPN, and ZTNA integrations enforce them at connection, and SSO integrations at sign-in, after which the application relies on the session token; access is decided at the relying party, not by issuance. Key protection varies by platform and integration: some access credentials are provisioned separately for compatibility.

Deploy inside your approved architecture

Run the platform hosted by Smallstep, or customer-operated as a VM appliance or Kubernetes install in your data center or cloud tenant, including disconnected environments. The inventory, policy, and issuance model is the same; air-gapped implementations need an approved architecture for local connectivity, attestation, certificate lifecycle, and updates. The hosted service is not FedRAMP authorized; customer-operated deployments are evaluated under your own system authorization.

Keep the PKI you were assessed on

Bring your root: your AD CS or HSM-held root signs a Smallstep intermediate. Your existing root CA private key remains under your control; intermediate key custody follows the deployment architecture you select. Device certificates chain to the root your RADIUS, VPN, and relying parties already trust, which can avoid distributing a new root; relying parties may still need the intermediate configured, the issuer allowlisted, or certificate-policy updates, and should require the Smallstep issuer where assurance matters.

Evidence an assessor can read

Every device credential issued through the device enrollment workflow maps to an inventory record: which device, which enrollment method, which user if assigned, when it was issued and renewed, and whether it was revoked. Removal from inventory stops issuance and renewal; existing certificates stay valid until expiry unless the authority publishes active revocation and the enforcement point checks it. Available records support your SSP, assessment evidence, and remediation documentation, alongside your relying parties' own logs.

Support assessments and authorizations

Smallstep helps public sector and defense IT teams implement certificate-based device authentication, manage device credentials, and keep records of issuance and revocation. Those capabilities can contribute to controls under NIST SP 800-171 Rev. 2, 800-172, and 800-53. Compliance with CMMC, FedRAMP, or any framework depends on your broader systems, policies, and assessor determinations, and Smallstep does not make an organization compliant on its own.

Make the network admit the devices you can account for.

One inventory, one policy, one CA. Your MDM delivers the profile; Smallstep issues under the policy you configure. Certificate-based device authentication under your inventory policy, deployed inside your boundary when it has to be, with records behind every credential.

Book a demo

Frequently asked questions about device identity for public sector and defense

Yes. The Department suspended CMMC Phase 2 third-party assessment requirements on July 13, 2026, with no restart date announced. Phase 1 self-assessments, DFARS 252.204-7012, NIST SP 800-171 Rev. 2, and a current SPRS score where required remain in force; DFARS 7012 and 7020 obligations apply by contract clause and are separate from CMMC. Device authentication is an 800-171 control today, whatever form third-party assessment takes later. See the DoD CIO CMMC page for current status.

No product does. Smallstep implements device identification and authentication and keeps the records behind it, which can satisfy parts of specific controls as your assessor interprets them. Compliance depends on your system boundary, policies, and the rest of your controls. We will show you exactly what each capability does and does not cover so your SSP says the same.

No. The hosted service is not currently FedRAMP authorized. Where a non-authorized SaaS service cannot be used, Smallstep offers customer-operated deployments as a VM appliance or Kubernetes install; the deploying organization evaluates the software, its dependencies, and its configuration under its own system authorization, change-control, and supply-chain processes. Placement inside a boundary is not approval by itself. Confirm which networks and systems sit inside your authorized boundary with your assessor.

Yes. The platform is available customer-operated as a VM appliance or a Kubernetes installer, with Terraform templates for AWS, Azure, and GCP tenants, and it supports disconnected environments. The standard agent documentation assumes reachability to Smallstep-hosted services for the agent API and attestation, so an air-gapped implementation requires an approved architecture covering local service connectivity, attestation, certificate lifecycle, updates, and operational dependencies; we validate the configuration with you before you depend on it. Self-hosted deployments can hold CA signing keys in a PKCS#11 HSM that meets the documented requirements. Hosted is the common choice where the boundary allows it; customer-operated costs more to run and support, and we will say so.

NIST SP 800-171 Rev. 2 requires FIPS-validated cryptography when protecting CUI confidentiality. Smallstep's cryptographic capabilities and module validation status vary by deployment architecture: the hosted platform keeps CA signing material in a managed cloud HSM, and customer-operated deployments have their own module set. FIPS-capable, FIPS-enabled, and operating with a validated module in an approved configuration are different claims; confirm the modules, configuration, and validation status with us before documenting them for an assessment. Certificate issuance by itself does not implement 3.13.11.

Most directly 3.5.2, identify and authenticate devices before establishing a connection, and 3.1.1, limit access to authorized devices. It is a separate device-authentication control alongside the user MFA that 3.5.3 requires; it does not satisfy 3.5.3 on its own. 3.13.11 depends on the cryptographic module in use. Under 800-172 as incorporated in CMMC Level 3, 3.5.1e asks for cryptographic, bidirectional, replay-resistant authentication, which properly configured mutual TLS with device certificates can support where the relying party supports it, and 3.5.3e requires mechanisms that prohibit connections from system components unless they are known, authenticated, properly configured, or within a trust profile; Smallstep contributes device identity and authentication evidence, and your enforcement architecture determines how connection authorization is implemented. NIST published 800-172 Rev. 3 in May 2026 with new identifiers; CMMC Level 3 still references the original. Your assessor decides what each control requires in your system.

A hardware-bound device certificate is a possession factor tied to a specific device. On its own it authenticates the device, not the person, so it does not replace user MFA. It is a device-authentication control alongside your user MFA, not an additional factor for the user account unless your authentication ceremony binds it to the user. Whether any combination satisfies 3.5.3 or an authenticator assurance level in your system is an assessor determination; we will not claim a level for you.

A hardware-bound device certificate is a possession factor tied to a specific device. On its own it authenticates the device, not the person, so it does not replace user MFA. It is a device-authentication control alongside your user MFA, not an additional factor for the user account unless your authentication ceremony binds it to the user. Whether any combination satisfies 3.5.3 or an authenticator assurance level in your system is an assessor determination; we will not claim a level for you.

Level 3 adds 800-172 enhanced requirements. Two of them map to what Smallstep does: 3.5.1e, cryptographic bidirectional replay-resistant authentication, through mutual TLS where the relying party supports it; and 3.5.3e, prohibiting connections from system components unless they are known, authenticated, properly configured, or within a trust profile, where Smallstep contributes identity and authentication evidence and your enforcement architecture implements the authorization. These are related but separate requirements, and a certificate alone does not establish configuration or trust-profile membership. Level 3 assessments are also paused and interpretations are not settled; build the capability now and document it against the enhanced requirements as incorporated in CMMC.

Smallstep integrates with Intune for inventory and SCEP; confirm GCC High endpoint support with us. AD CS can stay as your root: sign a Smallstep intermediate from it and device certificates chain to the root your domain already trusts, with NPS or ISE policy requiring the Smallstep issuer. See the bring your own root guide for the migration path.

Yes. The Smallstep agent enrolls Linux devices with TPM 2.0 attestation, alongside Windows and macOS, and workload certificates cover servers and services. On research systems that already rely on the TPM, Smallstep uses it to protect and attest identity keys; that does not verify disk encryption, secure boot, or configuration. Field and embedded hardware without a TPM is scoped case by case.

The mechanics are the same; the frameworks differ. State and local agencies map the same device authentication to 800-53 or state baselines, FFRDCs and university labs handling CUI fall under 800-171 through their federal agreements, and allied government teams map ACME device attestation to their own baselines where internally generated certificates issued on a username, password, and serial number need maturing. Tell us the framework and we will map the controls.

From Smallstep: the device inventory with source, approval state, enrollment method, and assigned user; certificate issuance and renewal history per device; revocation records on authorities with active revocation; and authentication activity where Smallstep RADIUS is in use. Access evidence for other enforcement points comes from those systems' logs, and records for a customer-operated CA from that deployment. These records support your SSP, assessment evidence, and remediation documentation; they are not an SSP or POA&M on their own. Ask us which exports your deployment option provides.