In the modern enterprise, the “perimeter” is no longer a physical office—it is the fleet of laptops and mobile devices in the hands of remote employees. However, managing the identity of these devices has remained stuck in the early 2000s.

If you are a security professional or IT admin, you know the struggle of ensuring that only your managed devices—and not a personal laptop or a spoofed machine—can access your VPN, Wi-Fi, and internal apps.

This is where ACME Device Attestation comes in. It represents the biggest leap in device identity and Zero Trust architecture in over two decades. Here is why it matters and how it works.

The Pain Point: “Is This Actually My Device?”

For most IT teams, the biggest headache is unauthorized access. You might have an MDM (Mobile Device Management) solution like Jamf or Intune, but how do you guarantee that the device requesting a certificate is the specific MacBook, iPad or iPhone you purchased?

The current risk is identity spoofing. If an attacker or a disgruntled employee manages to extract a configuration profile or a shared secret, they can trick your network into thinking their personal, unmanaged computer is a company-issued device.

The Legacy SCEP Approach

For the last 20 years, the industry standard for getting certificates onto devices has been SCEP. Simple Certificate Enrollment Protocol (SCEP) [RFC 8894] was originally designed for getting X.509 certificates to networking gear. The way it works is pretty simple: As long as the device knows the secret password and is configured to trust the organization’s Certificate Authority (CA), it can request a certificate for itself from the CA.

How SCEP works:

1. The MDM server sends a “Configuration Profile” to the device.
2. This profile contains a shared secret (password) and the URL of a Certificate Authority (CA).
3. The device presents that password to the CA to prove it is allowed to have a certificate.

The Problem with the Legacy Approach

While SCEP was revolutionary in 2010, it has three fatal flaws in a modern security environment:

1. Passwords can be stolen: SCEP relies on a shared secret. If an attacker intercepts the configuration profile, they have the password. They can then use that password to request their own certificate from any machine, successfully impersonating a managed device.
2. No Hardware Binding: SCEP doesn’t care where the private key lives. It doesn’t verify if the key is stored in a secure hardware chip (like Apple’s Secure Enclave or a TPM) or if it’s sitting as a file on a desktop that can be easily exported.
3. Manual “Trust Me” Validation: You are essentially trusting the device because it “knows a secret,” not because it “is a specific piece of hardware.”

The Solution: ACME Device Attestation

ACME (Automated Certificate Management Environment) [RFC8555] is the protocol that powered the Let’s Encrypt revolution for securing communications with web servers. Later, it has been adopted to automate certificate management for workloads in DevOps environment using a Private ACME CA server.

Standard ACME was designed for web servers and workloads to prove they own a domain (like example.com) using challenge types such as http-01, dns-01 and tls-alpn-01.

To make it work for devices, a new IETF draft named ACME Device Attestation Extension was created.

This extension introduces a new challenge type [device-attest-01] to the ACME protocol. Instead of proving you own a domain, the device must prove its physical identity. It is the bridge that allows the ACME protocol to talk to the hardware security chips (like Apple’s Secure Enclave) and transport that “proof” back to the CA.

In short:

ACME Device Attestation is a way for a device to prove its identity using hardware-backed evidence rather than a password. It allows a device to say to a CA: “I am Serial Number XYZ, and here is a cryptographic proof signed by the manufacturer (say, Apple) to prove it.”

Why is it Needed? (The Zero Trust Shift)

Zero Trust is built on the idea of “Never Trust, Always Verify.”

• Hardware-bound Identity: It ensures the private key is generated inside a secure chip and cannot be exported. Even if a hacker gains admin access to the laptop, they cannot steal the identity.
• Manufacturer-Verified: It leverages the trust you already have in the hardware manufacturer (Apple, Google, etc.) to verify the device’s physical attributes.
• Elimination of Shared Secrets: There are no more SCEP passwords to manage, rotate, or leak.

How ACME Device Attestation Works:

When a device (like an iPhone running iOS 16+ or a modern Mac) enrolls via ACME Device Attestation, the flow looks like this:

1. The Challenge: The device contacts the ACME Certificate Authority. The CA issues a “challenge” to the device.
2. The Attestation: Instead of just sending a password, the device generates a key pair in its Secure Enclave. It then creates an “attestation object” which includes the device’s permanent hardware identifiers (like Serial Number and UDID).
3. The Signature: This object is signed by a hardware-bound key that only the manufacturer (Apple) can verify.
4. Verification: Instead of relying on a password, your ACME CA performs a “Chain of Trust” validation. It uses the manufacturer’s Root CA certificate to verify the device’s signature. This confirms that the hardware is authentic. For an extra layer of security, the CA (often integrated with your MDM) can cross-reference the device’s unique hardware identifiers (like Serial Number or UDID) against your organization’s inventory list. This ensures that the certificate is only issued to a device your company actually owns.
5. Issuance: Once verified, the CA issues the certificate.

The Result: A “Secure” Perimeter

By moving from SCEP to ACME Device Attestation, organizations finally achieve the “Device-as-a-Password” dream.

The user experience is seamless—no logins, no manual certificate installs. From a security perspective, you gain the peace of mind that only the physical hardware you own can access your network. A stolen configuration profile is now useless to an attacker because they don’t have the specific, physical Secure Enclave chip associated with that device’s identity.

The era of the “shared secret” is over. The era of hardware-backed trust has arrived.

Ready to Upgrade Your Device Identity?

The shift from SCEP to ACME Device Attestation isn’t just a technical upgrade—it’s a fundamental requirement for a true Zero Trust architecture.

If you’re ready to move beyond vulnerable shared passwords and secure your fleet with hardware-backed trust, it’s time to look at BastionXP CA.

BastionXP provides a modern Private CA designed for the automation era. By supporting the latest ACME Device Attestation standards, BastionXP allows you to:

Eliminate SCEP Passwords: Automate certificate issuance without the risk of shared secret leaks.

Enforce Hardware Binding: Ensure that every certificate is cryptographically locked to the device’s Secure Enclave or TPM.

Seamless MDM Integration: Works alongside your existing tools (like Jamf, Intune, or Kandji) to provide a seamless, “no-login” experience for your users.

Don’t let legacy protocols be the weak link in your security chain.