How can security teams detect Pass the Certificate?

How to spot certificate-based logins that should not be there

pass the certificate often shows up as a normal certificate login at first glance, so the detection problem is really one of context. Focus on where the authentication happened, which host presented the certificate, and whether that combination makes sense for the account. If a certificate authenticates from a system or network segment that the user or service should not normally use, treat it as a stronger signal than the certificate event alone.

Look for mismatches between the certificate and the expected device context. A certificate may be valid, yet still be suspicious if the logon source, timing, or account history does not fit the normal pattern. Repeated use of the same certificate across multiple systems is especially important because it can indicate that a private key has been copied and reused rather than used from a single trusted device.

Certificate-based authentication is only one part of the story. Correlating identity events with endpoint telemetry, certificate issuance records, revocation status, and private-key location often exposes the gap that the login record by itself hides. The practical question is not only “was the certificate accepted?” but “was it accepted from the right place, with the right device, under the right lifecycle state?”

What telemetry is most useful for detection

Authentication logs should be read alongside endpoint and certificate lifecycle data, not in isolation. That includes certificate subject and issuer details, source host, source IP, account name, time of use, revocation state, and any endpoint evidence that the private key was present or exported. When those signals are correlated, unusual certificate use becomes easier to separate from legitimate machine-to-machine authentication.

Pay particular attention to reuse patterns. A certificate that appears on multiple hosts, across different network locations, or in parallel with other suspicious authentication activity deserves immediate review. In mature environments, the same certificate should usually have a narrow use case and a stable trust context. Broader appearance than expected can point to theft, duplication, or poor key handling.

The best detections are often the simplest ones: alert on certificate logins from unusual hosts, accounts, or geographies, then enrich the alert with endpoint data and certificate history. If the device context is missing, the account is not known to use that certificate, or the certificate was never expected on that system, the event should be escalated rather than treated as routine PKI noise.

What to do after a suspicious certificate login

When a certificate-based logon looks suspicious, move quickly to confirm whether the certificate is still trusted, where the private key is stored, and whether the same credential material has been used elsewhere. If the certificate is suspected to be compromised, revoke it and review dependent accounts, sessions, and systems that may still trust it. That step is especially important when certificate use is tied to persistent access or administrative workflows.

The response should also include a compromise check on the endpoint and account involved. A stolen certificate can be a symptom of broader exposure, not the whole incident. Investigate whether the private key was exported, whether an endpoint was compromised, and whether the same authentication pattern appears in other systems or at other times. If so, the issue may extend beyond one certificate and into a broader credential-handling weakness.

For certificate-based abuse paths, detection and response are tightly connected. The more quickly you can confirm issuance, usage, storage, and revocation state, the faster you can decide whether to rotate related credentials, quarantine a host, or treat the event as confirmed unauthorized access.

Risk and Threat Considerations

Pass the Certificate is dangerous because a valid certificate can make an attacker look like a legitimate user or service. If defenders do not correlate the certificate with the expected device, source, and lifecycle state, stolen key material can be reused quietly across multiple systems and turn a single compromise into durable access.

Failure mechanism: The attacker obtains or copies the private key, then presents a certificate that the relying system still trusts. Because the login can succeed without obvious password abuse, weak device context checks and poor certificate visibility let the activity blend into normal authentication traffic.

Impact: The result can be unauthorized access, account impersonation, lateral movement, and persistent access that survives ordinary password resets. In environments that rely heavily on certificate trust, revocation delays and weak inventory can leave a compromised certificate usable longer than defenders expect.

Practitioner Guidance

What to verify: Confirm that every certificate login can be tied to a known device, known account, and expected source location. If any one of those is missing, treat the event as suspicious until proven otherwise.

What to measure: Track how often certificate authentications occur from new hosts, new network ranges, or unexpected accounts. Those anomalies are often more actionable than raw authentication volume because they expose where trust is being reused outside its intended boundary.

Common mistake: Treating a successful certificate login as proof of legitimacy. A valid certificate only proves that the certificate was accepted, not that the key was still under the right holder’s control.

Practitioner takeaway: Good detection depends on context, not just cryptographic success, so the most valuable control is the one that can explain where the certificate came from, where it was used, and whether that use still fits the expected trust model.

Related resources from NHI Mgmt Group

• Guide: AD CS Security Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?