Public Key Infrastructure (PKI) was never designed for an environment where devices could drift out of compliance within hours, sometimes minutes, of being trusted. And yet, many organizations still rely on static models that issue certificates based on a single moment of verification. In a dynamic risk landscape, that model doesn’t hold up.
That’s where Dynamic PKI comes in. Dynamic PKI means certificate-based security that reflects the current state of a device, not just the moment it is enrolled. Dynamic PKI uses real-time device posture signals, policy-driven revocation logic, and conditional certificate workflows to maintain trust throughout the device lifecycle. However, not every component of the Dynamic PKI certificate issuance process is dynamic. Some parts, like ACME, serve a different role.
Automated Certificate Management Environment (ACME) is a major upgrade over static verification methods, like SCEP. Where SCEP relies on simple pre-shared secrets and API key validation, ACME enables strong identity verification before a certificate is issued. That means we can ask, “Is this device genuine?” before deciding to issue a certificate, not after the fact. That verification step, especially when combined with device attestation, dramatically reduces the risk of issuing certs to spoofed or unmanaged devices.
ACME device attestation enables organizations to bind certificate issuance to device authenticity, verified through cryptographic, hardware-backed methods. Let’s explore how ACME device attestation works, where it fits in the Dynamic PKI ecosystem, and why it’s rapidly becoming a best practice for identity-first security strategies.
What is ACME Device Attestation?
ACME is a well-established protocol for automating certificate lifecycle management. We extend ACME’s functionality to support device attestation, meaning it can be used to evaluate whether a certificate request is coming from a genuine, policy-compliant device at the moment of request.
Device attestation requires cryptographic proof that the request originates from known hardware. This is usually done by using components like the Trusted Platform Module (TPM) on Windows devices or the Secure Enclave on Apple hardware.
With Apple devices, the process includes a real-time verification step with Apple’s attestation servers. Here’s what happens: the device generates a cryptographic assertion using a key stored in the Secure Enclave. That assertion is sent to Apple, which confirms the device’s hardware integrity.SecureW2 receives this verdict, can validate that information with the device’s MDM,and use it to decide whether to issue a certificate, and if so, what kind.
This is not just about granting or denying access. It’s about making data-driven, real-time decisions based on reliable device signals. An unmanaged BYOD device might be issued a short-lived certificate with limited access. A fully managed, MDM-enrolled MacBook might be granted a long-term certificate with broader privileges.
ACME vs. SCEP: Rethinking Enrollment Protocols
Organizations traditionally used Simple Certificate Enrollment Protocol (SCEP) to automate certificate issuance. But, SCEP lacks a strong identity verification model. It relies on pre-shared secrets and doesn’t provide any true visibility into the requesting device’s security posture. Once the certificate is issued, it’s valid until expiration, regardless of whether the device becomes risky or noncompliant.
ACME, with device attestation, addresses these gaps. It doesn’t just check who is requesting the certificate; it confirms what the device is, whether it’s tamper-resistant, and whether it adheres to policy. This allows certificates to truly represent the presence of a trustworthy device.
Combined with our policy engine, ACME enables nuanced decisions during issuance. Certificates can be customized in scope, duration, or simply denied, based on real-time trust evaluations. It’s a major step forward from the binary, static logic of SCEP.
How ACME Device Attestation Works
The certificate enrollment process begins when a device contacts SecureW2’s ACME server. Before issuing a certificate, SecureW2 prompts the device to provide an attestation statement. On Apple devices, this triggers the Apple Managed Device Attestation protocol. The Secure Enclave signs the statement, which is then validated by Apple’s attestation service.
Apple confirms the device’s identity and returns an attestation result to SecureW2. This includes whether the device is genuine Apple hardware, whether it has a Secure Enclave and if the key was generated on it, and whether it’s MDM-managed. That attestation result becomes a key input to SecureW2’s policy decision: does this device meet our standards for trust? If so, what access should it have?
This policy-driven model means organizations can go beyond basic enrollment decisions. Devices might be segmented by access tier, use case, or security posture, enabled entirely through certificate-based policy enforcement.
Continuous Trust Beyond Issuance
Attestation at issuance is critical, but it’s only part of the story. Devices can fall out of compliance after receiving a certificate. That’s why SecureW2 extends ACME Device Attestation with continuous trust validation.
Integrations with security platforms like CrowdStrike, Microsoft Defender, Palo Alto, and MDM tools provide real-time telemetry about device risk. If a device becomes compromised or leaves MDM management, SecureW2’s platform can revoke its certificate automatically, cutting off access before that risk escalates.
This enables a model where trust isn’t a fixed point in time—it’s a dynamic, enforceable attribute. Organizations gain both control and clarity: they know exactly which devices have access, why, and for how long.
Why It Matters
In any strong access control strategy, decisions must be tied to real, verifiable context. ACME device attestation delivers that context at the most foundational layer—identity. It validates device identity using hardware-based cryptography and evaluates posture using real-time telemetry. And it allows organizations to build policies that reflect that trust.
If you’re still relying on static certificate issuance, it’s time to rethink your approach. PKI should reflect the state of your devices, not just at issuance, but always.
Radhika Vyas