What should organisations do if passwordless depends on certificates or PKI?

Why This Matters for Security Teams

When passwordless depends on certificates or PKI, the control surface does not disappear, it changes. The organisation is no longer protecting memorised secrets, but a cryptographic trust chain that can be just as dangerous if issuance, renewal, revocation, and recovery are weak. That is why certificate-backed passwordless must be treated as high-value identity infrastructure, not a convenience feature. The Ultimate Guide to NHIs — What are Non-Human Identities shows why lifecycle discipline matters: secrets and machine credentials fail most often when ownership is unclear and rotation is inconsistent. NIST’s NIST Cybersecurity Framework 2.0 reinforces the same practical point by tying identity governance to operational resilience, not just authentication strength.

Security teams often underestimate how quickly pki sprawl appears once passwordless is rolled out across laptops, service accounts, developers, and tools. The result is usually fragmented ownership, delayed revocation, and certificates that outlive the people, workloads, or devices they were meant to protect. In practice, many security teams encounter certificate failure only after an outage, an offboarding miss, or an audit finding, rather than through intentional lifecycle control.

How It Works in Practice

The practical answer is to govern certificates with the same rigor used for any other non-human credential, then add the controls that PKI specifically requires. Start with explicit ownership for each certificate class: user device certificates, service certificates, code-signing certificates, and automation certificates should not share the same process or approval path. Next, define issuance authority, renewal windows, revocation triggers, and recovery steps so the lifecycle is measurable rather than implicit.

For passwordless user authentication, organisations should prefer short-lived credentials and automated renewal where possible, because long-lived certificates create the same persistence risk as static passwords. For workloads and agents, pair certificate issuance with workload identity so the identity is bound to the runtime, not to a human-operated account. In mature environments, this often means combining PKI with policy-as-code and just-in-time approval logic, so the certificate is valid only for the intended device, workload, or session.

• Map every certificate to an owner, purpose, and expiry policy.
• Automate renewal and revocation where operationally feasible.
• Require offboarding hooks so employment or workload termination triggers certificate invalidation.
• Use inventory and monitoring to detect orphaned, duplicated, or shadow certificates.
• Test recovery paths for lost devices, broken trust chains, and emergency revocation.

The machine identity gap is not theoretical: SailPoint’s The Critical Gaps in Machine Identity Management report notes that only 38% of organisations have automated certificate lifecycle management in place, which helps explain why expiry and renewal failures remain operationally common. Current guidance suggests treating certificate management as an identity workflow, not a network task, because the failure modes are governance failures first and cryptographic failures second. These controls tend to break down in hybrid estates with legacy applications, where certificate ownership is unclear and renewal logic is still embedded in scripts, shared accounts, or manual ticketing.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger assurance against more frequent renewal events and more complex recovery procedures. That tradeoff becomes visible in environments that mix workforce devices, third-party integrations, and machine-to-machine authentication, because a single PKI policy rarely fits all three well.

Best practice is evolving for passwordless deployments that rely on PKI. Some organisations issue device certificates only and keep user authentication separate; others extend certificates to service identities, API access, or remote administration. There is no universal standard for this yet, so the safer approach is to define certificate classes by risk, not by technology stack. High-risk certificates should have shorter TTLs, stricter issuance approval, and stronger revocation monitoring than lower-risk internal-use certificates.

Edge cases also include emergency access, shared service endpoints, and offline recovery. In those situations, exception handling must be documented in advance, because “temporary” certificate exceptions often become permanent if no one owns the cleanup. For further context on how NHIs fail when visibility and ownership are weak, the Sisense breach is a useful reminder that credential trust chains are only as strong as their weakest lifecycle control. Organisations should align these controls with NHI governance rather than assuming passwordless is automatically safer.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?