Attackers use Pass the Certificate by authenticating with a stolen or forged certificate instead of a password or hash. If the certificate maps to a privileged identity, they can access services and persist without reusing stolen credentials. Defenders should protect private keys, limit certificate enrolment, monitor certificate-based authentication, and revoke compromised certificates where possible.
How Pass the Certificate works in practice
pass the certificate is a credential-replay path for certificate-based authentication. The attacker does not need the victim’s password or hash if they can present a usable certificate and its private key to the target service. That matters most when the certificate is mapped to a privileged account, because the access path can look legitimate to the relying system.
What makes this technique effective is that the certificate is the proof factor, not an optional add-on. In environments that still accept certificate logon or mutual TLS for privileged workflows, a stolen or forged certificate can substitute for a normal interactive sign-in and may survive password resets that would otherwise break access.
When certificate-based access is part of an enterprise identity design, the security outcome is shaped by key protection, issuance controls, and mapping rules. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful here because lifecycle discipline, not just the certificate object itself, determines how easy that access path is to abuse.
How attackers obtain or abuse the certificate
Attackers usually need one of three things: a stolen private key, a forged certificate from a compromised or trusted issuing path, or access to a certificate already enrolled to an identity they can impersonate. The attack can begin long before the target authentication event, through key theft, exportable key material, weak storage, overbroad enrollment, or compromise of the certificate authority workflow.
In Active Directory Certificate Services environments, the abuse often comes from template misconfiguration or weak subject mapping rather than from the cryptography itself. NHIMG’s AD CS Security Guide covers the abuse paths defenders need to think about when certificate enrollment or mapping is too permissive.
Attackers also value certificate replay because it can bypass controls that focus only on passwords, NTLM hashes, or interactive MFA prompts. If the certificate is valid and the target trusts the issuing chain and subject mapping, the service may authenticate the attacker as if they were the rightful holder of the key.
Why defenders should treat certificate replay as an identity problem
Pass the Certificate is not just a PKI issue, it is an access-control issue. If a certificate maps to a privileged identity, the attacker inherits whatever that identity can reach, including administrative services, automation interfaces, and long-lived service access. NHIMG’s Ultimate Guide to NHIs is relevant because certificate-based access is often part of service and machine identity architecture, where privilege can be broader and less visible than for human logons.
The defender’s real question is whether certificate authentication is being used as a strong proof of possession or as a convenient alternate login path with weak oversight. If revocation is slow, certificate enrolment is broad, or certificate-to-account mapping is inconsistent, attackers can keep using the certificate even after the initial theft is suspected.
For key handling and rotation policy, NIST SP 800-57 Key Management is the right external reference to anchor cryptoperiods, protection, and lifecycle discipline. For mutual-TLS and certificate-bound token use, RFC 8705 helps explain why binding matters when certificates are part of the access path.
Risk and Threat Considerations
Certificate replay becomes high impact when the certificate is tied to privileged access, service-to-service trust, or a legacy authentication path that is hard to monitor. The attacker is not trying to break the certificate format, they are trying to reuse trusted proof that the environment already accepts.
Failure mechanism: A stolen or forged certificate, together with its private key or a trusted issuing relationship, is presented to a service that still trusts certificate-based authentication and maps that certificate to an authorized identity.
Impact: The attacker can authenticate without the original password or hash, persist through some credential resets, and operate under the privileges of the mapped account until the certificate, key, or trust path is revoked or invalidated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate replay depends on key protection, rotation and lifecycle discipline. |
| Recommendation — Apply key lifecycle rules to protect, rotate and retire certificate private keys. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service, Workload, and API Access) | Certificate-based authentication is an access-control mechanism for non-human or service identities. |
| IA-5 — Authenticator Management | The attack abuses stolen or forged certificate material as an authenticator. | |
| Recommendation — Enforce certificate-based authentication with strong identity binding and limited scope. Manage certificate issuance, storage, rotation and revocation as authenticators. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | A stolen certificate private key enables unauthorized certificate-based authentication. |
| NHI-05 — Overprivileged NHI | A mapped certificate can inherit excessive privileges if the identity is too broad. | |
| Recommendation — Protect certificate private keys and revoke any exposed certificate material. Limit certificate-mapped identities to the minimum privileges needed. | ||
Practitioner Guidance
What to verify: Confirm which services accept certificate authentication, which identities those certificates map to, and whether any of those identities have administrative reach, automation privileges, or broad east-west access. The highest-risk cases are certificates that can authenticate to more than one system or that map to shared or privileged identities.
Decision rule: If a certificate can authenticate a production system and the private key may be exposed, treat it as a live credential compromise, not as a configuration nuisance. Rotate or revoke first, then investigate whether the certificate was abused before the alert.
What good looks like: Certificates are short-lived where practical, private keys are non-exportable or strongly protected, enrollment is tightly scoped, and certificate-based logons are logged with enough detail to distinguish normal machine use from suspicious replay.
Practitioner takeaway: The core control objective is not to eliminate certificate authentication, but to ensure that any certificate capable of proving identity is tightly issued, tightly mapped, and quickly revocable when compromise is suspected.