Introduction

A PKI migration can introduce the new smart card issuing CA while Windows logon still validates certificates through the old one. Users insert cards and get inconsistent logon prompts, one domain controller accepts the new cards while another still expects the retired issuer, or authentication fails only after the previous CA is decommissioned because NTAuth publication, trust stores, revocation paths, and certificate mapping policy often move unevenly.

Treat this as a certificate-validation path problem instead of a generic smart card failure. Start by checking which issuing CA, NTAuth entry, and revocation path an affected smart card logon actually depends on, because migrations often validate new certificates on a test workstation while domain logon infrastructure continues trusting the earlier PKI chain.

Symptoms

  • Smart card logon still validates against the old CA after migration
  • New cards fail on some systems while older cards continue to work
  • One domain controller or workstation accepts the new CA while another still expects the previous issuer
  • Logon fails only after the retired CA or revocation service is removed
  • Certificate prompts appear, but Kerberos or domain logon still depends on the old PKI path
  • The issue started after moving AD CS, smart card issuance, or domain trust infrastructure

Common Causes

  • NTAuth still publishes the old CA while the new issuer is missing or not replicated everywhere
  • Domain controllers or clients still trust the retired CA chain in local or Group Policy stores
  • CRL, AIA, or OCSP paths still point to the previous PKI environment
  • Certificate templates or mapping policy were updated in one domain segment but not another
  • Smart card middleware or workstation images still ship the old trust chain
  • Validation confirmed the new CA could issue cards but did not verify how live domain logons actually validated them

Step-by-Step Fix

  1. Capture one affected smart card logon and record the issuing CA, NTAuth entry, and revocation path it actually uses, because the runtime validation chain determines whether Windows accepts the card for domain logon.
  2. Compare that active validation chain with the intended post-migration PKI design, because one stale NTAuth or trust-store entry can keep many systems tied to the retired CA.
  3. Review NTAuth publication, enterprise trust stores, domain controller certificate policy, CRL or AIA endpoints, and smart card certificate templates for references to the old issuer, because smart card logon depends on directory trust and revocation together.
  4. Check different domain controllers, workstation images, and sites separately if behavior differs, because migrations often fix one validation path while another still relies on the previous CA.
  5. Update the authoritative trust and certificate-validation configuration so affected logons validate against the intended CA chain, because deploying the new issuer alone does not retarget domain logon trust.
  6. Perform a controlled smart card sign-in and confirm the intended CA and revocation path are used end to end, because a visible certificate prompt does not prove the right trust chain accepted it.
  7. Verify the old CA and revocation endpoints no longer participate in migrated smart card logons, because split PKI validation can remain hidden while both infrastructures stay reachable.
  8. Review replication, revocation availability, and certificate EKU or mapping settings if logons still fail, because the destination can be correct while trust data or policy still blocks authentication.
  9. Document which team owns NTAuth publication, domain trust policy, and smart card validation testing so future PKI cutovers verify the real logon trust path before retiring the previous CA.