HOW TO BUILD YOUR OWN DEVICE IDENTITY SOLUTION.

Linda Ikechukwu

Follow Smallstep

To buy or build? That’s the question.

About once a month, someone forks our open source CA, tries to build a device identity system on top, gets overwhelmed, and eventually calls us in. We always say, talk to us, even if you’re not sure where the budget will come from.

If you do, you could save yourself from future headaches.

You probably landed here because you’re building towards a more secure, zero trust infrastructure. Maybe your PKI has become unmanageable. Maybe a security incident made device identity a board-level concern. The 2023 LastPass breach showed us why device trust matters.

Attackers exploited a vulnerability in a third-party media software installed on the engineer’s home computer, allowing them to install keylogger malware. This enabled the attackers to capture the engineer’s master password after multi-factor authentication, granting them access to the corporate vault containing decryption keys for customer data. This wasn’t a failure of passwords or MFA. It was a failure to verify the device.

In a Zero Trust model, continuous evaluation of device identity (based on hardware backed credentials), is just as critical as verifying the user. More teams are realising that hardware-attested device identity is the missing piece. They add “use hardware attestation” to their policy checklist, go tool-hunting, and often land on our open source certificate authority project, and probably go “oh cool, we’ll just build our own device identity solution with this.”

step-ca is robust. It’s trusted by 78 of the Fortune 100 and has replaced fragile, homegrown PKI setups across the world. But it's just a CA server. It was built for DevOps use cases, not device identity. And it takes more than a CA server to build a robust device identity solution. You’ll need attestation logic, inventory, user bindings, data sync, endpoint configuration, and policy logic. You’ll also need cryptography experts, a dedicated team, time, and more money than it’d cost you to buy our software.

We’d love for you to use our platform. And we’d caution against rolling your own. Even Meta, who built theirs on our open source, recommends thinking twice:

“People see open source attestation code and think, let’s just deploy that and see if we can get some attested certs on the device… And I think that’s a bit shortsighted. There’s just so much more involved. We were able to do it cos we’re Meta. Most organizations do not have these existing infrastructure and the resources Meta has. ” ~Jesse from Meta

But if you still want to build it yourself, we won’t stop you. In fact, we’ll tell you how.

What our open source step-ca can do for you

Since inception, step-ca has been one thing: a certificate authority for internal DevOps workflows. It issues certificates. It does not judge whether a device is trustworthy. When teams try to use it to build cross-platform device identity in-house, they eventually reach out to us with requests to “add TPM support”. But step-ca already supports the TPM attestation format, and step-cli has basic tooling for it. What’s missing isn’t the ACME plumbing, it’s the attestation verification logic, essential for proofing that a device is what it says it is.

We saw this play out in real life at Meta. At the time, Meta’s biggest challenge was verifying that a device requesting a certificate actually belonged to them. Many of their workflows depend on client certificates. But before issuing those, how do you know the request is coming from a real, trusted device? Device attestation through the ACME device-attest-01 challenge solves that. It proves that a hardware-backed key was generated on a legitimate machine.

Meta also didn’t want to burden employees. If a device can prove itself automatically, users don’t need to jump through hoops just to get a certificate. The coolest thing about device identity is how it enables secure remote provisioning. A laptop can ship straight from the manufacturer to a remote user, and on first boot, it proves its identity with a certificate, letting the company confirm it’s the exact device they expected, without ever touching it.

For the device-attest-01 challenge, instead of proving ownership of a DNS name, a device uses hardware-backed attestation obtained via TPM, Secure Enclave, or another root of trust to prove it is itself. Here’s how it works in summary:

1. The device receives an ACME payload from the MDM, which defines certificate request parameters and how to interact with the ACME server (like step-ca).
2. The device generates a hardware-bound private key inside a TPM or Secure Enclave and initiates a certificate order with the ACME server.
3. The ACME server responds with a device-attest-01 challenge, instructing the device to prove that the key was generated on trusted hardware.
4. The device contacts an attestation server (for Apple devices, this is Apple’s attestation service), which returns a signed attestation certificate proving that the private key is bound to legitimate hardware.
5. The device submits this attestation evidence to the ACME server as proof of identity, and as proof of the private key having been generated on trusted hardware.
6. The ACME server validates the attestation itself using the root certificate(s) of the Attestation CA, confirming the device’s trustworthiness.
7. If verification succeeds, the ACME server issues a certificate from the organization’s CA. The device installs the certificate in its keychain and uses it to authenticate to services like MDM, Wi-Fi, SaaS apps, and web apps. Because the private key is hardware-bound, the certificate cannot be exported or stolen.

For Meta, Apple devices were the easiest to secure because Apple runs its own Attestation CA. The Secure Enclave signs a JWT as part of the ACME flow, which includes an attestation certificate issued by Apple’s Attestation CA. Combined with MDM profile delivery and Apple’s published trust anchors, this makes device verification seamless. step-ca fits perfectly into that flow.

Outside of the Apple ecosystem, device identity is a nightmare. TPMs, are a mess. There are many manufacturers, each with slightly different attestation formats. Trust chains are often inconsistent or unavailable. While step-ca can handle the device-attest-01 challenge and verify TPM attestation, it depends on having the correct manufacturer trust roots and validation logic in place. To manage this complexity, Meta had to build their own attestation CA to handle verification and then returns a signed result that the ACME client includes in its response to step-ca.

Now imagine trying to extend ACME DA to SSH access, Kubernetes workloads, ephemeral cloud VMs, or sensitive developer tools. That’s a full-blown trust infrastructure. You’re going to need more than a CA.

Other things you need for a robust device identity platform

As Meta rightly knew, there’s so much that goes into building a viable device identity solution for an entire organization. You’re going to need more than an ACME CA server. You’re going to need more than step-ca.

Attestation CA

As explained previously, device attestation often requires a dedicated Attestation CA. A standard CA can issue certificates based on simple data like a domain name. Device attestation, however, is more specialized because it must verify hardware claims. An attestation CA checks that a device’s secure chip truly protects its private keys and meets the criteria for issuance. The attestation CA typically integrates with hardware vendors’ root-of-trust systems such as Apple’s Secure Enclave attestations or Microsoft’s endorsement keys for TPM. This process ensures that only machines with a valid hardware identity are enrolled.

Smallstep comes with an Attestation CA built by our security engineers so that TPM 2.0 devices in complex, multi-platform environments can obtain clean, standardized, and attested device certificates.

Device Inventory

You can’t enforce device authentication if you don’t know what devices exist. That’s why inventory is foundational. Smallstep maintains a real-time device inventory by syncing with systems like Jamf Pro for macOS and Intune for Windows. Devices that don’t appear in this inventory are automatically denied credentials. No Wi-Fi, no VPN, no app access.

Our short-lived, hardware-bound certificates issued through ACME Device Attestation ensure that even if a certificate is stolen, it won’t work on another device. We also support Dynamic SCEP for legacy environments, offering a smooth migration path away from shared, static secrets. Meta already had strong asset tracking in place, giving them confidence in tying certificates to physical devices, serial numbers, and supply chain records.

Endpoint Configuration

MDMs handle endpoint configuration well, until they don’t. Certificate renewal, revocation, and coordination across systems introduce complexity. Not every device is managed equally. Linux machines are often left out. Apple MDMs can issue device certificates via the Secure Enclave, but most Apple MDMs can issue device certificates bound to the Secure Enclave. While many Windows MDMs support requesting TPM-backed keys, they typically don’t prove the key actually resides in a TPM, so the proof isn’t high assurance. Even something as basic as distributing Git credentials falls outside the scope of most MDM tooling.

Smallstep smooths out these inconsistencies. Our agent runs on macOS, Windows, and Linux, unifying certificate management and endpoint configuration across platforms. It can run on a schedule or be triggered when a device attempts to connect to a secure resource.

User Bindings

A strong device identity system doesn’t stop at the device. You also need to know who’s using it. Smallstep integrates with identity providers like Okta and Azure AD to bind each certificate to a verified user. This user-device binding ensures certificates aren’t issued to orphaned machines or passed between unauthorized users. Before a certificate is issued, the user authenticates via your IdP, and the resulting certificate reflects both the device and the authenticated user.

With both device identity and user authentication in place, you can define precise policies like: “Only a developer in the production group, using an approved laptop, can SSH into production.” Before building their device identity system with step-ca, Meta had already established a similar structure, connecting internal and third-party SSO systems to employee data.

Before setting out to build a device identity solution with step-ca, Meta had a similar structure in place, with both internal and third-party SSO systems tied to employee data.

Enforcement Points and Policy Engine

Once you have identity, configuration, and user bindings sorted, you still need enforcement. In simple cases, that might mean requiring mutual TLS. But at scale, you need enforcement points that integrate with your infrastructure—ZTNA solutions, transparent VPNs, RADIUS servers, and access gateways that can evaluate both user and device identity in real time.

Smallstep provides these enforcement points along with a policy engine that evaluates every access attempt to ensure that only recognized devices and authorized users can access sensitive systems.

Meta had to build their own version of this, a centralized certificate decision engine that verifies policy, user binding, and device records before issuing certificates.

Before you build, do you have what Meta has?

It’s tempting to look at Meta’s example and think, “If they did it, we can too.” But before you go down that path, ask yourself: do you have the same foundation as they do?

Meta didn’t just plug step-ca into their environment and call it a day. They had years of internal tooling, infrastructure, and talent in place. A few examples:

1. They had internal building blocks. Meta already had:
   • A reliable internal CA platform
   • A certificate decision engine
   • A supply chain system to track devices by serial number
   • A real-time device inventory
   • Multiple authentication systems already in place
2. They had people who had done it before. Meta’s team included engineers with hands-on experience building TPM attestation systems. They weren’t starting from scratch, they knew the protocols, the quirks, and how to wire everything together. Do you have that kind of in-house expertise?
3. It still took two months. Even with Venky’s experience and Meta’s internal infra, it took nearly a full quarter to wire everything up, deploy the service internally, and get it production-ready.
4. They had capable teams. Teams that owned MDM, internal tooling, endpoint security, supply chain, policy management. Do you?
5. They had scale justification. For a company with tens of thousands of devices and extremely high security requirements, investing engineering effort to build in-house made sense. For most companies, it doesn’t.

Smallstep is the cost effective option

If you tried to build even just one of the components, say, a secure, continuously synced device inventory, you’d likely need: 1–2 full-time engineers, 3–6 months of dev and testing time plus maintenance overhead for as long as the system is live. That’s hundreds of thousands of dollars in engineering time. And that’s just one piece. Multiply that by five or six other essential components, and suddenly you’re looking at a million-dollar project.

Or, you could pay a fraction of that to use Smallstep’s commercial Device Identity Platform. It’s already built, tested, and maintained by the team that wrote the open source foundation you’re basing your project on.

Building means you’re on the hook for keeping up with shifting ecosystems. MDM APIs change. IdPs evolve. Device vendors update firmware and attestation formats. When you use Smallstep’s commercial platform, you’re not just getting software, you’re getting a partner with deep integrations and relationships across the identity and device security ecosystem.

And when things break (as they inevitably will) you’ll need support. Not just docs or ChatGPT or StackOverflow threads, but engineering backstop. That’s baked into our commercial product.

Device identity isn’t just a tactical checkbox. It’s the foundation for long-term trust. And trust needs to evolve. That’s what we’ve built for.