Register for part 2 of our Device Identity Webinar Series!

Keyfactor governs the certificate estate. Smallstep decides which devices can use it.

Keyfactor governs the certificates you have. Smallstep proves which devices should get one, with hardware evidence before issuance.

Book a demo
background gradientbackground texture
Hardware provenance at enrollment
Non-exportable, hardware-bound keys
Authorization against a trusted device record
Checked at the enforcement point
Enrollment over ACME device-attest-01
Evidence from hardware to access

Certificate lifecycle and device trust are different questions.

Lifecycle management asks what happens to a certificate once it exists: discovery, renewal, revocation, governance across every CA in the estate. Device identity asks one step earlier, whether this device should receive a trusted credential at all. A capability can appear in both models, and where it sits relative to issuance decides whether it solves the problem end to end.

  • "Nobody knew that certificate existed" is a lifecycle question
  • "Can this endpoint prove itself before Wi-Fi or VPN" is a trust question
  • Collapsing the two produces the wrong shortlist

Enrollment gated on hardware evidence, not a shared secret

Smallstep checks inventory and attestation evidence before issuance, then completes ACME device-attest-01 with a key generated in the TPM or Secure Enclave. Nothing enrolls on a SCEP challenge phrase anyone can copy.

A certificate proves a key. An inventory turns it into an authorization.

A certificate says someone holds the private key. It doesn’t say that key sits in a device you own and approved. Smallstep syncs inventory from Jamf Pro, Intune, Workspace ONE UEM, Mosyle, Iru, Fleet and Google Workspace, or via API, and stops renewing a device’s credentials when it leaves inventory, with active revocation on Advanced Authorities.

Smallstep authorizes issuance. The enforcement point checks the credential.

The two get conflated. Smallstep decides which devices receive and keep a trusted credential, and that one credential gates Wi-Fi, VPN, SSH, internal apps, and SSO. At access time Smallstep is often the checker, through its managed RADIUS (or, where available, its relay). Sometimes it is your ISE or your IdP.

When a certificate lifecycle platform is the right starting point

Governance across many CAs, public or trusted TLS, and document or artifact signing are lifecycle problems, and Keyfactor is built for them. Identity for products you manufacture can start on either side. Many enterprises need both layers. Replacing AD CS? See where each fits.

Keep Keyfactor where it governs. Add device identity where access is decided.

Attested enrollment, authorization against a trusted device record, and an evidence trail from device hardware to the decision that permitted access.

Book a demo

FAQs Smallstep for Keyfactor Environments

Not in most environments. A mature certificate management platform and a device identity platform address related but different parts of the trust landscape, and they can be complementary. Evaluate each against the specific trust decision you need to make.

The certificate lifecycle layer governs the estate: the certificate is the primary object, the authoritative record is a certificate inventory across CAs and stores, and the ongoing work is discovery, renewal, revocation, and reporting. The enterprise device access layer governs which devices reach protected resources: the device is the primary object, the authoritative record is a trusted device inventory synced from MDM, and the ongoing work is re-attestation and continued approval. This is the layer each system is designed to govern, not a claim about what either vendor is capable of building.

Keyfactor's center of gravity is the certificate estate: discovery, inventory, renewal, and governance across many CAs. Smallstep's is the trust decision that precedes issuance: whether a device has proved a hardware-bound key and belongs in the inventory before it gets a credential the infrastructure trusts.

Depends on what AD CS is doing for you. If it issues machine and user certificates for Wi-Fi, VPN, SSO and internal apps, Smallstep replaces it: SCEP and NDES emulation for what must stay, attested ACME enrollment for the rest, and your existing root on an Advanced Authority. If it also serves Kerberos smart-card logon or a large estate of server and application certificates across many CAs, a lifecycle platform like Keyfactor belongs in the evaluation too. The AD CS business case kit walks through both.

It authorizes issuance, and depending on the pattern it may also operate the enforcement point. Smallstep integrates with three protection patterns: direct mutual TLS where the resource checks the certificate, a proxy or relay, and RADIUS. Smallstep operates a managed EAP-TLS RADIUS service, and it also works with third-party enforcement points such as Cisco ISE or ClearPass, where those systems make the runtime decision.

That the private key was generated inside a hardware security component on that device and can be presented with attestation evidence at enrollment. It is the starting point of a device-trust decision, not the whole decision.

A device-trust decision has four parts: hardware provenance, a trusted inventory record, enforcement at the access point, and lifecycle evidence you can reconstruct afterward. Issuance covers one of them.

Yes. EJBCA lists device-attest-01 among its ACME challenge types, and Keyfactor’s docs state that EJBCA ACME Device Attestation “supports Apple devices only,” developed and tested with Jamf. The Spring 2026 update highlights ACME device attestation for hardware-backed device identity at enrollment. Both vendors implement the same IETF draft. Smallstep also attests Windows and Linux TPMs, and ChromeOS through Google Verified Access. Compare the documented platform coverage, what the attestation is validated against, and how the result is carried to the enforcement point, rather than treating the challenge type as the deciding factor. Note also that Apple Managed Device Attestation requires iOS 16, iPadOS 16.1 or macOS 14 or later on A11 or Apple silicon hardware, and that application support for hardware-bound keys is uneven on every platform.

For connected products, yes. Keyfactor Command for IoT and EJBCA cover identities for devices you manufacture, from the production line through end of life, including IDevID issuance. That is a different requirement from enterprise device access, where the question is whether an employee endpoint can prove itself before reaching Wi-Fi, VPN, SSH, or SaaS. Sort which one you are solving before comparing products.

No, and the limit is worth knowing. Many client applications cannot use a hardware-bound key directly. Where that is true, the Smallstep agent issues short-lived provisioned credentials, authenticated to the CA with the hardware-bound key. The protection level varies by application, operating system, and use case, and Smallstep publishes that matrix in its documentation rather than averaging it into a single claim. Ask either vendor for the same breakdown.

When the primary requirement is governance across a heterogeneous certificate environment: many CAs, many trust stores, and enterprise PKI operations that need visibility, renewal automation, and reporting before anything else.

A need for public CA certificates is a distinct requirement from operational device identity. Evaluate it on its own terms rather than folding it into a device access project.

The device credential issued to the machine’s hardware security component, verified by a RADIUS server during the EAP-TLS handshake. Smallstep operates a managed RADIUS service that validates the chain and checks revocation on every authentication, and it also works with RADIUS servers you already run. Enterprise RADIUS can also call your webhook on every authentication, so a failed posture check can deny the connection.

Certificates are short lived and have to renew, so removing the device from the inventory and revoking its credential ends access rather than leaving a long-lived certificate in circulation. Removing access is a sequence, not a single event, so ask any vendor to demonstrate it end to end and to show how the record supports reconstructing the decision later.

Keyfactor’s Spring 2026 update adds composite (classical + quantum-safe) certificates and expanded PQC support for hardware-backed signing. Smallstep’s short-lived, automatically renewed certificates let supported algorithm changes roll out at renewal rather than by re-enrollment. Teams with near-term PQC mandates should test both vendors’ current support directly.

The Smallstep Agent is documented for Windows, macOS, and Linux, each requiring a TPM 2.0 or Secure Enclave. ChromeOS enrolls through the Smallstep extension using Google Verified Access. Smallstep integrates with MDMs that support Dynamic SCEP, including Jamf, Intune, Workspace ONE, Mosyle, Ivanti, and Google Workspace.