Cross-Cutting Guides intermediate 11 min read

Device Posture in Zero Trust: Continuous Verification Beyond Username and Password

device-posture zero-trust tpm mdm endpoint-security continuous-verification

Device Posture in Zero Trust: Continuous Verification Beyond Username and Password

The Problem With Identity-Only Access Control

A valid username and password, or even a valid FIDO2 token, tells you that the right person is trying to authenticate. It tells you nothing about the device they are authenticating from. That device could be an unpatched laptop with a known RCE vulnerability, a personal machine with no disk encryption, a VM spun up by an attacker who stole the user’s session cookie, or a managed corporate workstation that last checked in with your MDM three months ago.

Zero trust architecture requires that every access decision evaluate both identity and context. Device posture is the device-side context: a structured set of signals that, together, let you assert whether the machine requesting access is trustworthy at this moment.

The problem is not philosophical. In the 2021 Okta breach, attackers moved through the environment using a compromised support laptop that passed credential-based authentication. In the 2023 MGM Resorts incident, attackers initiated access after social engineering — but the lateral movement was possible because device state was not a factor in access decisions once inside. Getting authentication right without evaluating the endpoint leaves a large gap.

What Device Posture Actually Means

Posture is a composite score or set of boolean signals. No single signal is sufficient; the combination is what matters.

Device identity certificate. The device holds a certificate issued by your corporate PKI, bound to a hardware key that never leaves the device. This is the foundational signal — without it, you cannot trust any other posture claim, because the entity providing the claims is unidentified.

OS patch level. The operating system version and the date of the most recent security update. A device running macOS 14.3 with January 2025 patches, when a critical kernel vulnerability was patched in February, is not current. Policy typically enforces maximum patch age (e.g., no more than 30 days behind current).

Disk encryption status. FileVault on macOS, BitLocker on Windows, LUKS on Linux. Verified as enabled and with a key escrow record retrievable by IT. A device without disk encryption means any physical theft results in full data exposure.

Endpoint agent running. Your EDR or endpoint management agent is installed, running, and has checked in recently. This is both a compliance signal and a prerequisite for other posture data — if the agent is not running, the signals it would provide are absent.

Screen lock and inactivity policy. Maximum inactivity timeout, whether the screen lock requires the same strong credential or allows PIN bypass.

Jailbreak or root detection. On mobile devices: whether the device’s secure boot chain has been tampered with. On laptops: whether Secure Boot is disabled or the boot chain shows unexpected measurements (checked via TPM PCRs).

Firewall enabled. Platform firewall enabled and not disabled by user override.

Browser and application versions. Some policies extend posture to require that specific applications (VPN client, browser used to access the service) meet minimum versions.

These signals are gathered by an agent, an MDM, or both, and presented to the access policy engine — either at login time, continuously during a session, or on a short polling interval.

TPM-Bound Device Certificates

The Trusted Platform Module (TPM) is a secure cryptographic coprocessor present in most corporate laptops manufactured after 2016. The TPM’s critical property for device identity: private keys generated inside the TPM cannot be exported. The key material never exists in software-accessible memory in cleartext.

When your corporate PKI issues a device certificate, the certificate’s private key should be TPM-bound. The enrollment process works as follows:

  1. The enrollment agent (Intune, Jamf, or a custom SCEP/EST client) instructs the TPM to generate a key pair. The TPM returns the public key; the private key remains inside the TPM.
  2. The enrollment agent constructs a Certificate Signing Request (CSR) containing the TPM-generated public key and sends it to your issuing CA via SCEP or EST.
  3. The CA issues the device certificate and returns it to the enrollment agent, which stores the certificate alongside a reference to the TPM key handle.
  4. To prove possession of the certificate, the device signs a challenge using the TPM. The TPM performs the signing operation internally — the private key never crosses the TPM boundary.

The attestation chain extends this further. TPMs can produce a signed attestation statement — signed by the TPM’s Endorsement Key (EK), which is burned into the hardware by the manufacturer — that certifies the key was generated inside the TPM and is not exportable. Your CA can verify this attestation before issuing a certificate, ensuring that a device is not just claiming TPM binding but cryptographically proving it.

On Windows, the TPM attestation flow is handled by the Microsoft Platform Crypto Provider. The key storage provider Microsoft Platform Crypto Provider is the interface for TPM-backed keys. Intune’s PKCS certificate profile can request TPM attestation as a prerequisite for enrollment.

On Linux, TPM key binding uses tpm2-tools and the tpm2-pkcs11 PKCS#11 provider, which bridges the TPM to standard PKCS#11 interfaces:

# Create a primary key in the TPM owner hierarchy
tpm2_createprimary -C o -g sha256 -G ecc -c primary.ctx

# Create a signing key under the primary, non-exportable by construction
tpm2_create -C primary.ctx -g sha256 -G ecc \
  -r device-sign.priv -u device-sign.pub \
  --attributes "fixedtpm|fixedparent|sensitivedataorigin|sign|noda"

# Load the key into a PKCS#11 token
tpm2_ptool addkey --algorithm=ecc256 --label=device-identity \
  --userpin="$(cat /etc/tpm2-pkcs11-pin)" --primary-label=primary

The fixedtpm and fixedparent attributes in the --attributes flag are the enforcement mechanism: a key with these attributes cannot be duplicated or moved to another TPM. The private key is physically bound to this specific TPM.

Corporate PKI: Issuing Device Certificates via SCEP and EST

SCEP (Simple Certificate Enrollment Protocol) is the legacy workhorse for device certificate issuance. EST (Enrollment over Secure Transport) is the modern replacement, using HTTPS and mutual TLS rather than SCEP’s HTTP with PKCS#7 wrapping.

In a Jamf environment, SCEP is configured under Settings > PKI Certificates. Jamf acts as a SCEP proxy, forwarding enrollment requests to your internal CA (EJBCA, Microsoft ADCS, or a cloud CA like AWS Private CA). The Jamf enrollment profile delivered to macOS devices includes:

<dict>
    <key>PayloadType</key>
    <string>com.apple.security.scep</string>
    <key>PayloadIdentifier</key>
    <string>com.example.device-identity.scep</string>
    <key>PayloadContent</key>
    <dict>
        <key>URL</key>
        <string>https://scep.internal.example.com/scep</string>
        <key>Name</key>
        <string>DeviceIdentity</string>
        <key>Subject</key>
        <array>
            <array><array><string>CN</string><string>$SERIALNUMBER</string></array></array>
            <array><array><string>O</string><string>Example Corp</string></array></array>
        </array>
        <key>KeyType</key>
        <string>RSA</string>
        <key>KeySize</key>
        <integer>2048</integer>
        <key>KeyUsage</key>
        <integer>5</integer>
    </dict>
</dict>

In Intune, the equivalent is a PKCS Certificate profile or a SCEP Certificate profile. The SCEP profile references a Trusted Certificate profile (the root CA certificate) and the SCEP server URL exposed by your NDES (Network Device Enrollment Service) or a third-party SCEP proxy. Intune variables like {{DeviceId}} and {{SerialNumber}} are available in the Subject field, allowing per-device certificate subjects.

For EST, the enrollment request uses standard HTTPS POST to /.well-known/est/simpleenroll, with the request body as a base64-encoded PKCS#10 CSR. EST provides a cleaner security model than SCEP because it uses TLS for transport security rather than relying on a pre-shared password in the SCEP challenge.

Integrating Device Certificates into IAP via mTLS

Once a device holds a certificate, it can present that certificate during TLS handshakes to resources that enforce mutual TLS. An Identity-Aware Proxy (IAP) is the natural enforcement point.

The flow for an mTLS-enforced IAP:

  1. Device initiates a TLS connection to the IAP endpoint.
  2. IAP presents its server certificate; device validates it.
  3. IAP requests a client certificate; device presents its TPM-bound device certificate.
  4. IAP validates the device certificate against the corporate CA trust store, checking the chain of trust and CRL/OCSP status.
  5. IAP extracts the device identity (typically the CN or a SAN) from the certificate and passes it to the policy engine alongside the user identity from the bearer token.
  6. Policy engine evaluates user.identity AND device.certificate.valid AND device.posture.compliant.

In Envoy (a common IAP data plane), this looks like:

listeners:
- name: iap_listener
  address:
    socket_address: { address: 0.0.0.0, port_value: 443 }
  filter_chains:
  - transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
        require_client_certificate: true
        common_tls_context:
          tls_certificates:
          - certificate_chain: { filename: /etc/iap/server.crt }
            private_key: { filename: /etc/iap/server.key }
          validation_context:
            trusted_ca: { filename: /etc/iap/corporate-ca-chain.pem }
            crl: { filename: /etc/iap/corporate-device-crl.pem }

The corporate CA chain must include only the sub-CA that issues device certificates, not your full root hierarchy. Scoping the trusted CA to device issuance prevents other certificate types (user certificates, server certificates) from satisfying the device mTLS requirement.

BeyondCorp Enterprise (Google), Cloudflare Access, and Zscaler Private Access all support device certificate verification as a native access policy condition. In Cloudflare Access, a Device Posture rule of type “Client Certificate” matches against the SHA-256 fingerprint or issuer CN of the device certificate presented at the Cloudflare edge.

CAEP and SSE: Revoking Sessions When Posture Degrades

Static posture verification at login is insufficient. A device that was compliant at 9 AM may become non-compliant at 11 AM — the EDR agent stopped, the VPN client was uninstalled, a vulnerability scan found a critical finding. The session established at 9 AM continues unless something terminates it.

The Shared Signals and Events (SSE) framework and its profile Continuous Access Evaluation Profile (CAEP) address this. SSE defines a standard protocol for security event publishers (your EDR, MDM, SIEM) to push real-time signals to event receivers (your IdP, IAP, resource server). CAEP defines the specific event schema for access evaluation — session revocation, credential change, device compliance change.

The architecture has three roles:

  • Transmitter: the system detecting the posture change (Jamf detecting FileVault disabled, CrowdStrike detecting EDR agent stopped, Intune detecting device compliance policy failure).
  • Receiver: the system that enforces access decisions (Okta, Entra ID, your custom IAP).
  • Subject: the device and/or user whose access is being re-evaluated.

A CAEP session-revoked event pushed from a transmitter to a receiver causes the receiver to immediately invalidate active sessions associated with that device. The event is a JWT, signed by the transmitter:

{
  "iss": "https://compliance.example.com",
  "aud": "https://idp.example.com/sse/receiver",
  "iat": 1746700000,
  "jti": "abc123",
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "subject": {
        "format": "email",
        "email": "user@example.com",
        "device_id": "device-uuid-here"
      },
      "reason_admin": {
        "en": "Device compliance failure: FileVault disabled"
      },
      "initiating_entity": "policy",
      "event_timestamp": 1746700000
    }
  }
}

The receiver endpoint validates the JWT, looks up active sessions for the subject, and terminates them. Okta supports SSE receivers natively. For custom IAPs, you implement the SSE receiver endpoint — a webhook that accepts signed Security Event Tokens (SET) — and wire it to your session store.

The practical result: when Jamf detects that a MacBook has had FileVault disabled, it fires a CAEP event within seconds. The IdP terminates all sessions. The user gets logged out and must re-authenticate from a compliant device. End-to-end revocation time is measured in seconds rather than hours or the next re-auth cycle.

Linux Endpoint Posture Without MDM

Linux desktops in most enterprise environments do not have MDM management equivalent to Jamf or Intune. This creates a posture gap: Linux devices may hold valid device certificates but emit no structured posture signals.

The practical approach is a custom attestation agent combined with osquery.

osquery runs SQL-like queries against the local system state. A posture query pack covers the signals you care about:

-- Disk encryption status
SELECT de.encrypted, de.name
FROM disk_encryption de
WHERE de.name LIKE '/dev/sd%' OR de.name LIKE '/dev/nvme%';

-- Kernel version and last update
SELECT version FROM kernel_info;
SELECT date, source FROM deb_packages
WHERE name = 'linux-image-generic'
ORDER BY date DESC LIMIT 1;

-- Running security agents
SELECT name, state FROM services
WHERE name IN ('falcon-sensor', 'osqueryd', 'auditd', 'aide');

-- Firewall status (iptables)
SELECT default_policy FROM iptables_chains WHERE chain='INPUT' AND table='filter';

The attestation agent collects osquery results, reads TPM PCR values for boot integrity, signs the combined payload with the TPM-bound device key, and submits it to a posture service:

# Read PCRs 0-7 (BIOS, option ROMs, MBR, bootloader measurements)
tpm2_pcrread sha256:0,1,2,3,4,5,6,7 --output pcrs.bin

# Sign the posture payload using the TPM key via PKCS#11
openssl dgst -sha256 -sign "pkcs11:token=device-identity;object=device-sign" \
  -keyform ENGINE -engine pkcs11 \
  posture-payload.json > posture-signature.bin

The posture service stores the signed attestation and the PCR values. PCR 0 contains the firmware measurement, PCR 4 the bootloader. If the PCR values deviate from a known-good baseline (the golden measurements captured at enrollment), the device fails posture even if all other signals are clean — indicating a potential bootkit or Secure Boot bypass.

The agent runs on a short interval (90–300 seconds) and posts results to an internal posture API. The IAP’s policy engine queries this API on each request or on a token-refresh interval.

macOS: Platform SSO and Secure Enclave-Backed Credentials

macOS 13 introduced Platform SSO, which integrates the macOS login credential with enterprise IdPs (Entra ID, Okta) using a local authentication plugin. The device certificate in this architecture lives in the Secure Enclave — Apple’s hardware security module embedded in Apple Silicon and T2 Macs — rather than in a software keychain.

The Secure Enclave provides the same non-exportable key guarantee as a TPM. Keys created with the kSecAttrTokenIDSecureEnclave attribute cannot be extracted from the device. Platform SSO uses these Secure Enclave keys for the device identity assertion passed to the IdP during SSO flows.

With Jamf Pro and Jamf Connect configured for Platform SSO, the enrollment flow automatically provisions a Secure Enclave-backed credential during macOS login. The credential is used for both local authentication and as the device identity presented to services that check it. Jamf’s Compliance Reporter can push posture signals to Okta via the SSE/CAEP interface, closing the loop between device state and session validity.

For the device certificate itself, macOS configuration profiles can specify com.apple.security.pkcs12 to use the Secure Enclave key rather than a software key by setting KeyIsExtractable to false and allowing AllowedApplications only to the system keychain daemon.

Common Evasion Techniques and Mitigations

Stolen device certificates. If an attacker exfiltrates a device certificate from a machine where the private key is software-stored (not TPM/Secure Enclave bound), they can replay the certificate from another device. The mitigation is mandatory hardware binding: your CA’s enrollment policy must require a TPM attestation statement before issuing a device certificate. Certificates issued without hardware attestation should be in a separate, lower-trust CA hierarchy.

Virtual machines passing posture checks. An attacker running a VM configured to match expected posture signals — correct OS version, expected processes running, expected filesystem layout — can pass software-based posture checks. TPM attestation partially addresses this: virtual TPMs exist, but their EK certificates are issued by hypervisor vendors, not hardware manufacturers. Your enrollment policy can reject EK certificates from known virtual TPM issuers (VMware, Hyper-V, QEMU). More robustly, UEFI Secure Boot state combined with PCR measurements provides a fingerprint that is difficult to forge in a VM environment because the PCR values reflect the real boot chain.

Agent spoofing. An attacker on a non-compliant device could run a modified version of your posture agent that returns fabricated results. The mitigation is cryptographic signing of posture reports: the agent signs its report with the TPM-bound device key, and the posture service verifies the signature. An attacker on a different device cannot produce a valid signature without the specific device’s TPM key. A modified agent on the correct device is a harder attack — one that requires persistent code execution — and is caught by EDR behavioral detection.

Certificate reuse after device decommission. A device certificate issued with a 1-year validity continues to be cryptographically valid after the device is wiped and decommissioned, unless revoked. Your device lifecycle process must revoke the certificate at decommission time, and the IAP’s mTLS validation must check CRL or OCSP on each connection. Caching CRL responses for more than a few hours creates a window where a revoked cert is still accepted.

User-initiated compliance bypass. On devices where the user has local administrator rights, disabling FileVault, killing the EDR agent, or modifying the osquery configuration is straightforward. This is why posture signals need to be validated server-side and why MDM-enrolled devices should have configuration profiles that prevent disabling critical security controls. On macOS, a System Extension MDM profile can prevent unloading the EDR kernel extension. On Windows, Intune’s Tamper Protection prevents stopping the Defender for Endpoint service from user mode even with admin rights.

Putting It Together: Policy Evaluation

A practical access policy for a sensitive internal service combines these signals:

ALLOW if:
  user.authenticated = true
  AND user.mfa_method IN ["fido2", "platform_authenticator"]
  AND device.certificate.valid = true
  AND device.certificate.issuer = "CN=Device Sub-CA,O=Example Corp"
  AND device.certificate.hardware_bound = true
  AND device.posture.disk_encrypted = true
  AND device.posture.os_patch_age_days <= 30
  AND device.posture.edr_agent_running = true
  AND device.posture.last_seen_minutes <= 5
DENY otherwise

The device.posture.last_seen_minutes <= 5 condition enforces currency: if the device’s posture agent has not checked in within 5 minutes, the posture data is stale and the request is denied. This prevents an attacker from using a device that has been offline and whose posture state has degraded without the server knowing.

The combination of hardware-bound identity (TPM certificate), real-time posture signals (MDM or attestation agent), continuous session evaluation (CAEP), and strict policy evaluation at the access proxy closes the gap that credential-only authentication leaves open. A stolen password gets an attacker nothing if the device they are using does not have a valid, hardware-bound device certificate and a current compliant posture report.