Should IAM teams prioritise PKI or device governance for passwordless security?

Why passwordless security cannot be won by PKI alone

Passwordless sign-in only works when the trust chain stays valid from authenticator to endpoint to session. PKI gives you a cryptographic root of trust, but it does not answer whether the device is still healthy, enrolled, compliant, or under administrative control. That is why passwordless programmes fail when teams treat certificate trust as a substitute for endpoint trust.

For passwordless deployments, the important question is not “Is the credential signed?” but “Should this device still be trusted to present that credential?” A passkey or certificate can be perfectly valid while the endpoint has drifted, been compromised, or fallen out of policy. Device governance is what keeps that trust decision current across inventory, posture, ownership and revocation.

This is why rollout design has to join authentication engineering with endpoint governance. The stronger the authentication proof, the more damaging it is if the device layer is blind to loss, theft, unmanaged reuse or policy exceptions. Passwordless and Passkeys Guide covers the sign-in side of that control, including phishing-resistant authenticators and recovery considerations.

Where PKI stops and device governance starts

PKI establishes that a key, certificate, or passkey-backed assertion can be trusted according to its binding and issuance rules. Device governance decides whether the endpoint carrying that trust should remain enrolled and allowed to use it. In practice, these are complementary controls: one proves the authenticator is legitimate, the other proves the device context still deserves access.

That distinction matters because device state changes faster than certificate math. A laptop can be out of patch compliance, have its management agent removed, be reassigned, or be operating outside a defined ownership boundary while still presenting a valid credential. Device and IoT Identity Guide is useful here because it treats device trust, attestation, and lifecycle as first-class access inputs rather than optional metadata.

PKI also has a narrower job than many IAM programmes assume. It does not maintain asset inventory, enforce post-enrolment posture, or decide whether a device should be quarantined after a trust event. Those are governance questions, not certificate-validation questions. When teams collapse both into one control, they end up with strong cryptography wrapped around weak endpoint acceptance policy.

What “prioritise” should mean in an IAM roadmap

The right priority is not a binary choice between PKI and device governance. IAM teams should sequence them as a layered control model: establish the cryptographic trust anchor, then require device governance signals before that trust can be used for access. If the programme only funds one layer, the likely failure mode is either insecure issuance without endpoint control or brittle endpoint policy without a trustworthy authenticator.

For most enterprises, device governance deserves equal operational attention because it is what turns passwordless from a login method into an access decision. That means ownership, inventory, posture, revocation, and exception handling need to be explicit, not implied. Cloud Workload Identity Guide is a good analogue for the general principle that trust is safest when it is short-lived, tightly scoped, and evaluated in context.

Teams should also be careful not to let rollout velocity hide weak recovery design. If device governance cannot rapidly disable lost, non-compliant, or reassigned endpoints, passwordless becomes easier to deploy but harder to contain when something goes wrong. Active Directory and Entra ID Hardening Guide supports the broader identity control point that strong sign-in only works when privileged access paths and trust boundaries are hardened too.

Risk and Threat Considerations

Passwordless security fails when attackers or accidental drift can preserve one side of the trust chain while breaking the other. A valid credential on an unmanaged or compromised endpoint can still deliver access, so the real exposure is trust persistence after the device should have been denied, remediated, or revoked.

Failure mechanism: The credential remains cryptographically valid while the endpoint loses governance coverage, allowing a stale, stolen, or non-compliant device to continue presenting trusted sign-in material.

Impact: Unauthorized access can persist past enrolment loss, device compromise, or policy violation, which defeats the main security promise of passwordless and increases the blast radius of a single endpoint failure.

Practitioner Guidance

What to prioritise: Treat device trust signals as an access control input, not a reporting metric. If the device state cannot be checked at sign-in, the control is only partially passwordless.

What to verify: Confirm that certificate or passkey validity, device ownership, management status, and revocation all feed the same access decision. If any one of those checks is manual or delayed, build an exception path for it.

Common mistake: Teams often finish PKI first and assume device governance can be added later. In practice, that order creates an attractive but incomplete control, because the authenticator is strong while the acceptance boundary stays weak.

Practitioner takeaway: Passwordless security is only as strong as the weakest trust gate, so the correct operating model is to verify the authenticator with PKI and verify the endpoint with governance before granting access.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams prioritise data security investment across IAM and governance programmes?
• How should security teams govern non-human identities at scale?