Certificate Sign-In (PKINIT)

With PKINIT, the AS request carries data signed with the certificate's private key in place of an encrypted timestamp, and the reply key is protected with public-key cryptography instead of the password. The DC maps the certificate to an account, then issues a TGT as it would for a password, writing event 4768 to its Security log with the certificate's issuer, serial number and thumbprint.

Mapping is the deciding check. A strong mapping ties the certificate to one account by something that cannot be reused, such as the account's SID inside it or an explicit mapping by issuer and serial number. Since KB5014754 became enforced by default in February 2025, with compatibility mode removed that September, DCs refuse a certificate that maps only by a name or carries another account's SID, writing Kdcsvc event 39 or 41 to the System log.

Key Trust needs no certificate issued to the account. The DC finds the account by public key and accepts it if the account's msDS-KeyCredentialLink attribute holds that key, which is how Windows Hello for Business key trust signs in. Write access to that attribute therefore lets someone sign in as the account, as a password reset would, and deserves the same auditing.

Because no password is involved, the DC puts the account's NTLM credentials, its NT hash, in the PAC, encrypted with the AS reply key, so NTLM single sign-on still works. A certificate therefore gives the NT hash too, and a password reset does not cancel it. Revoke the certificate, and remove any mapping or key that should not be there.

A certificate for a privileged account can come from a template that lets the requester name the subject, or from a sign-in relayed to web enrolment, which the Certificate Services abuse page covers. On the certification authority (CA), events 4886 and 4887 in the Security log record each request and each certificate issued, where Certification Services auditing and the CA's audit filter are on.