Register for part 2 of our Device Identity Webinar Series!

DigiCert documents ACME device attestation for Apple. Ask what the rest of your fleet receives.

On its documented ACME device-attestation path, DigiCert validates attestation before issuance, and that path currently supports Apple devices only. On Windows and Linux, the Smallstep agent presents TPM attestation evidence that the issuer validates before the certificate is signed.

Book a demo
background gradientbackground texture
TPM attestation on Windows and Linux
Apple Managed Device Attestation via MDM
Endorsement key checked against inventory
Issuer validates evidence before signing
Managed RADIUS for EAP-TLS available
Automated renewal, rotation, and revocation

Key storage and key attestation are different controls.

A key held in a secure element and a key proved to the issuer are two separate properties, established by two separate mechanisms. DigiCert Trust Assistant documents non-exportable TPM 2.0 keys on Windows 11, which is secure storage and worth having. Attestation is the issuing service validating hardware evidence before it signs.

  • Non-exportable means the key cannot leave the device
  • Attested means the issuer checked the hardware before signing
  • A fleet can have the first without the second

Attested enrollment is not uniform across a fleet.

Both vendors document ACME device attestation, so a yes on each line item separates nothing. The narrower question is which enrollment path is available on the platforms your fleet actually runs, and what the remaining devices receive instead.

The issuer validates TPM attestation before issuing the device certificate.

The agent creates an attestation key in the TPM. The Attestation CA verifies that the request comes from a device in inventory where the endorsement key is resident, issues an attestation certificate, and the agent uses it to complete ACME device-attest-01. Evidence first, signature second.

Managed RADIUS for EAP-TLS, or the RADIUS you already run.

DigiCert’s integration list includes no RADIUS, so a DigiCert-issued Wi-Fi certificate still needs a RADIUS server you run. Smallstep offers a managed RADIUS service for EAP-TLS that trusts your Smallstep authority directly and supports major access point vendors. If you already run Cisco ISE, ClearPass, or NPS, the same credential works there instead.

When DigiCert is the right starting point

Publicly trusted TLS and S/MIME, governance across a heterogeneous estate, and dated post-quantum obligations are DigiCert’s. Connected-product identity is a workflow question rather than a vendor split: both offer it, and the OEM/ODM page covers Smallstep’s.

An all-Apple fleet whose only requirement is an attested certificate is one DigiCert’s documented path can serve. If it also needs inventory-gated issuance, managed RADIUS, or Wi-Fi, VPN, and SSO configuration, evaluate the whole path on Apple too. Most teams run both: DigiCert keeps public TLS, Smallstep issues private device identity.

Evaluate the path the whole fleet receives.

Test the enrollment path on the platforms that matter, separate secure key storage from issuer-validated attestation, and choose the operating model that matches the access decision.

Book a demo

Smallstep and DigiCert, answered

Usually not. DigiCert’s portfolio is broader than device identity and covers requirements Smallstep does not address at all, publicly trusted TLS among them. In practice the two coexist simply: DigiCert keeps public TLS, Smallstep issues private device identity, and no integration is required. Evaluate each against the specific requirement you are funding.

Yes, and it deserves full credit. Trust Lifecycle Manager documents ACME device attestation and states that it validates each device's attestation before issuing a certificate from a DigiCert Private CA. The documentation also states that ACME device attestation currently supports Apple devices only, enrolled through an MDM such as Jamf. The evaluation question is not whether it works. It is what share of your fleet it covers.

Non-exportable describes where the key lives: generated in the TPM or secure element and unable to leave it. Attested describes what the issuer verified: the issuing service checked hardware evidence before it signed. DigiCert Trust Assistant documents non-exportable TPM 2.0 keys on Windows 11, which is key storage rather than issuer-validated attestation. Both are real controls and they are established by different mechanisms.

DigiCert’s documented ACME device attestation path covers Apple devices through an MDM. Smallstep documents TPM-backed attestation on Windows and Linux through its agent, and on Apple it uses Managed Device Attestation through the MDM path. Smallstep also publishes assurance levels per platform and application: Windows, Linux, and agentless Apple enrollment reach device attested, while several macOS agent workflows are Smallstep attested, a lower level. The comparison that matters is the one run against your own platform mix, not against a single flagship platform.

DigiCert's documented Intune integration enrolls via SCEP, with other Windows routes including Trust Assistant and Active Directory Autoenrollment. Smallstep's agent supplies TPM attestation evidence on Windows, and where the agent cannot run, dynamic SCEP is available as an agentless fallback that Smallstep documents as less secure than cryptographic device attestation.

The agent creates an attestation key in the TPM and requests an attestation certificate. The Attestation CA verifies that the request comes from a device in your inventory where the TPM endorsement key is resident, then the agent completes ACME device-attest-01 to obtain the device certificate. The proof and the authorization happen in the same sequence. Smallstep supports discrete and firmware TPM 2.0, so what the evidence establishes is the key’s residency in that device’s TPM, validated by the issuer, rather than a claim about a particular chip.

Then DigiCert’s attested path can cover enrollment, provided every device meets Apple’s Managed Device Attestation prerequisites. Apple documents those as iOS 16 and macOS 14 or later with only Apple silicon Macs supported, and notes that serial number and UDID are withheld under User Enrollment.

An all-Apple fleet whose only requirement is an attested certificate is one DigiCert’s documented path can serve. If the requirement also includes inventory-gated issuance, managed RADIUS, renewal tied to inventory, or Wi-Fi, VPN, and SSO configuration, evaluate the whole path on Apple too. DigiCert documents the attestation step; ask how the rest of the path is delivered.

Worth stating plainly. For several macOS agent workflows Smallstep documents its lowest protection level: possession of a private key without proof that it resides in a genuine Secure Enclave. Application support for hardware-bound keys is uneven across every platform, and Smallstep publishes that matrix rather than averaging it into one claim. Ask either vendor for the same breakdown.

The device credential issued to the machine’s hardware security component, verified by a RADIUS server during the EAP-TLS handshake. DigiCert does not provide RADIUS, so its Wi-Fi certificates rely on a server you operate. Smallstep operates a managed RADIUS service that trusts your authority directly, validates the full chain, and checks revocation on every authentication. It is certificate-only by design, with no PEAP and no MAC authentication bypass. It also works with the RADIUS you already run.

Yes, for the credentials it issues: hardware-backed key generation and attestation, issuance, short-lived rotation, policy-based renewal gating, and revocation, with automatic service reloads and centralized logs. What it does not do is discover and govern certificates issued by other CAs across a heterogeneous estate, which is what Trust Lifecycle Manager is built for.

That is DigiCert’s, and it is a separate requirement from private device identity. Smallstep issues private trust. If a program needs certificates the public internet already trusts, scope that on its own terms rather than folding it into a device access project.

That program is about to get busier. Under CA/Browser Forum ballot SC-081, the maximum public TLS lifetime has been 200 days since March 15, 2026, drops to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029. Renewal automation is the urgent part of a public TLS program, and it is DigiCert’s to run. Private device certificates from Smallstep already renew automatically on short lifetimes, so that side of the estate is off the calendar.

DigiCert Device Trust Manager targets device manufacturers across design, build, and operation, documenting multiple enrollment protocols and a TrustEdge request format using TPM 2.0 for device attestation. Smallstep serves that market too, with manufacturing-time or first-boot enrollment, hardware-backed attestation, and automated rotation and revocation across fleets; see the OEM/ODM page. The split is about the workflow rather than the vendor.

DigiCert is further along, and it is worth saying so. It documents post-quantum algorithm support including ML-KEM, ML-DSA, and SLH-DSA. Smallstep has shipped the hybrid TLS key exchange using ML-KEM and has not yet shipped hybrid X.509 certificates or a hybrid CA. If a dated PQC obligation is the primary requirement, evaluate it on the lifecycle side.

Yes. Trust Lifecycle Manager can connect to a self-hosted step-ca, Smallstep’s open-source CA, as a private issuer. In practice the two coexist more simply: DigiCert keeps public TLS, Smallstep issues private device identity, and no integration is required.

Windows 10 or later with TPM 2.0, macOS 13 or later on Apple silicon, and enterprise Linux distributions with TPM 2.0. Windows Home editions are not supported. ChromeOS is handled through a separate configuration path with Google Workspace rather than through the agent. Requirements are in the agent documentation.

Yes. Smallstep works as a drop-in replacement for Active Directory Certificate Services, with backwards-compatible support for SCEP and NDES so legacy workloads keep functioning, and it can adopt your existing root CA rather than forcing a new trust anchor.