FIDO2 Key Writeback to AD: What That Attribute Does

I registered a FIDO2 security key in Entra ID, waited one Entra Connect sync cycle, and found the key's public key sitting on my on-premises user object in msDS-KeyCredentialLink. So FIDO2 key writeback to Active Directory is real — which is interesting, because Microsoft's documentation says it does not happen. It is also never used for authentication, which is the part that actually matters. This post covers where the entry comes from, why no domain controller ever reads it, and what a passwordless sign-in really relies on when the internet is down.

Key Takeaways

• Entra Connect's built-in NGCKey sync rules copy FIDO2 and passkey public keys from the cloud-side searchableDeviceKey attribute into on-premises msDS-KeyCredentialLink — the writeback is observable in any lab with the right permissions.
• Despite the synced entry, Cloud Kerberos Trust is the only mechanism for FIDO2 sign-in to on-premises resources; the domain controller validates a partial TGT from Entra ID and never looks at the FIDO key material.
• Microsoft's hybrid FIDO2 FAQ states that Entra Connect "doesn't write info back" — that is true for the authentication mechanism but contradicts what the sync rules visibly do to the attribute.
• Offline sign-in after the first online logon uses cached credentials unlocked via the security key's hmac-secret extension; NTLM fallback rides on an NT hash the client retrieved through a Kerberos key list request, while fresh TGT acquisition fails until Entra ID is reachable again.
• Legitimately synced key credentials are exactly the baseline noise a shadow credentials detection has to account for, so knowing what writes them is a defensive win in itself.

Environment

• On-premises Active Directory at Windows Server 2016 schema level or higher, with the Azure AD Kerberos server object created for Cloud Kerberos Trust.
• Microsoft Entra Connect with its AD DS connector account holding write permission on msDS-KeyCredentialLink (mine has it via the Key Admins group).
• A hybrid-joined Windows 11 client and a hardware FIDO2 security key that supports the hmac-secret extension.
• The DSInternals PowerShell module for parsing key credential blobs.
• Entra ID P1 for the surrounding Conditional Access and device controls.

The Problem

The original question I wanted to answer was about outage resilience: if Entra ID is unreachable, can my domain controllers validate a FIDO2 credential on their own? The documentation seemed clear enough. The passwordless security key sign-in to on-premises resources guide describes exactly one mechanism — Cloud Kerberos Trust — and the FAQ flatly states that Entra Connect does not write anything back from Entra ID to Active Directory. Passkeys were going in anyway, sitting behind the Conditional Access baseline I covered earlier, so I built the lab to see what an outage actually breaks.

Then the lab disagreed with the documentation. After registering the security key in Entra ID and letting a sync cycle run, my on-premises user object had a populated msDS-KeyCredentialLink attribute, and the entry was unmistakably the FIDO2 key. Two official claims — "the only trust path is the cloud" and "nothing is written back" — and at least one of them looked wrong from where I was standing. It turns out the writeback is real and the trust claim still holds, and the distance between those two facts is worth understanding before you design anything around either.

The Solution — Tracing FIDO2 Key Writeback into Active Directory

Step 1 — Confirm the FIDO2 key landed in msDS-KeyCredentialLink

Raw msDS-KeyCredentialLink values are DN-Binary blobs and tell you nothing by themselves. The DSInternals module parses them into something readable, including the key usage type and, for FIDO entries, the token model:

Get-ADUser -Identity testuser -Properties msDS-KeyCredentialLink |
    Select-Object -ExpandProperty msDS-KeyCredentialLink |
    Get-ADKeyCredential

On my test user, the parsed entry came back with Usage set to FIDO and Source set to AzureAD, with the FIDO key material identifying the exact security key model I had registered minutes earlier in the Entra portal:

Usage  Source  Created    Owner
-----  ------  -------    -----
FIDO   AzureAD 6/10/2026  CN=Test User,OU=Users,DC=corp,DC=contoso,DC=com

No Windows Hello for Business enrollment, no on-premises registration step — just a passkey registered in the cloud, an Entra Connect delta sync, and the public key is in Active Directory.

Step 2 — The NGCKey sync rules that perform the writeback

When a user registers a FIDO2 key or a Windows Hello for Business credential, Entra ID stores the public key on the user object in the searchableDeviceKey attribute. Entra Connect ships, by default, with a rule pair that moves it downward: In from AAD – User NGCKey imports the cloud value into the metaverse, and Out to AD – User NGCKey exports it to msDS-KeyCredentialLink on the matching on-premises user. The rules predate passkeys — they exist for Windows Hello for Business Hybrid Key Trust — but they do not discriminate by usage type, so FIDO entries ride along.

The reason many admins have never seen this is permissions. The export only succeeds if the Connect AD DS connector account can write msDS-KeyCredentialLink, which it typically only has if it is in the Key Admins or Enterprise Key Admins group or was delegated the attribute explicitly. Installations that predate the Windows Server 2016 schema usually lack the permission, and the export fails silently — no error a user would ever notice, and FIDO2 sign-in works regardless. Which is the first hint about how load-bearing this attribute is not.

Step 3 — Why the domain controller never reads the FIDO entry

Here is the part that makes the writeback an oddity rather than a feature. When a user signs in to Windows with a FIDO2 key, Entra ID validates the assertion and returns a Primary Refresh Token plus a partial TGT — a minimal Kerberos ticket containing only the user's SID, signed with the key of the krbtgt_AzureAD account that the Azure AD Kerberos server object created in your domain. The client hands that partial TGT to a domain controller, and the DC exchanges it for a full TGT by validating the signature. At no point does the KDC look up the user's FIDO key material. The entry your sync wrote in Step 1 is dead weight in this flow.

Key credentials with NGC usage are a different story — those are what domain controllers validate via PKINIT in the Windows Hello for Business Hybrid Key Trust model, and that path genuinely works without Entra ID. FIDO-usage entries have no consumer in the KDC at all. Microsoft's hybrid FIDO2 deployment FAQ even answers the question "why can't we have the public key registered to on-premises AD DS so there's no dependency on the internet" — with the explanation that they deliberately wanted FIDO2 to work without certificates and PKI. The same FAQ's claim that Entra Connect "doesn't write info back" is, charitably, about the authentication mechanism rather than the sync engine. The attribute in my directory says the sentence could have been worded better.

This is testable in both directions. Remove the synced entry and FIDO2 sign-in to on-premises resources keeps working. Keep the entry but remove the Azure AD Kerberos object, and on-premises SSO dies, populated attribute and all.

Step 4 — What FIDO2 sign-in uses without internet connectivity

So if the on-premises key copy does nothing, what happens after the first sign-in when the device has no internet? The first logon must be online — that is documented and matches what I saw. After that, Windows falls back to cached sign-in, and the mechanism is the security key's hmac-secret extension: the machine stores a salt locally at enrollment, and at offline logon the key — after PIN or biometric — computes an HMAC over it with a secret that never leaves the hardware. The derived value unlocks the cached logon data. This is why Microsoft requires hmac-secret support on compatible keys; without it, offline unlock does not work at all.

For on-premises resources during an Entra outage, three things happen at once. Kerberos tickets from the last online session keep working until they expire — the full TGT is an ordinary AD ticket and the DC keeps issuing service tickets against it with no cloud involvement. New TGT acquisition fails, because a fresh partial TGT only comes with a PRT refresh from Entra ID. And NTLM quietly bridges some of the gap: during online sign-ins the client sends a Kerberos key list request and the DC returns the user's NT hash so passwordless users can still authenticate to NTLM-only resources — a design decision with its own offensive implications, documented thoroughly in Dirk-jan Mollema's Cloud Kerberos Trust research. Whether that NT hash survives into a purely cached session is not cleanly documented anywhere I found, so treat NTLM-during-outage as something to verify in your own environment rather than a guarantee.

Step 5 — Use the synced entries as a shadow credentials baseline

The defensive payoff of understanding this writeback is detection. The shadow credentials technique abuses exactly this attribute: an attacker with write access plants their own key credential on a target object and authenticates as that target via PKINIT. Tools like Whisker make it a one-liner. If you monitor msDS-KeyCredentialLink changes with Event ID 5136 — the same directory service change auditing I lean on for on-premises Kerberos detections — you need to know what legitimate writes look like, or the alert drowns.

The baseline is narrow: legitimate entries are written by the Entra Connect AD DS connector account, and parsed with Get-ADKeyCredential they show Source: AzureAD with usage FIDO or NGC. A write performed by any other principal, or an NGC-usage entry appearing on a user who never enrolled Windows Hello for Business — or on a computer object, where Entra Connect has no business writing at all — is worth an immediate look. Without knowing about the NGCKey writeback, the legitimate sync traffic and the attack look identical in the event log.

Frequently Asked Questions

Does Entra Connect write FIDO2 keys back to on-premises Active Directory?

Yes, despite documentation suggesting otherwise. The default Out to AD – User NGCKey sync rule exports the cloud-side searchableDeviceKey value — which includes FIDO2 and passkey public keys — into msDS-KeyCredentialLink, provided the connector account has write permission on the attribute.

Can a domain controller authenticate a FIDO2 key against msDS-KeyCredentialLink?

No. The KDC only validates key credentials with NGC usage, which belong to Windows Hello for Business Hybrid Key Trust. FIDO-usage entries have no consumer; FIDO2 sign-in to on-premises resources works exclusively through the Cloud Kerberos Trust partial TGT exchange.

What does FIDO2 sign-in use when there is no internet connection?

Cached sign-in, unlocked via the security key's hmac-secret extension — entirely local to the machine. Kerberos tickets from the last online session keep working until expiry, but acquiring a new TGT requires Entra ID to be reachable.

Why does Microsoft's FAQ say Entra Connect does not write info back?

The statement describes the Cloud Kerberos Trust mechanism, which genuinely does not depend on any writeback. It ignores the NGCKey sync rules, which visibly do write key material to the attribute. Both things are true at once; the FAQ just picked the less observable one.

Should I disable the NGCKey writeback if I do not use it?

You can disable the Out to AD – User NGCKey rule or simply withhold the attribute permission, and FIDO2 sign-in is unaffected. Leave it alone if you run Windows Hello for Business Hybrid Key Trust, because that deployment model depends on the same rule.

Conclusion

This post exists because my lab contradicted the documentation, and the resolution turned out to be "both are misleading in different directions". The writeback the docs deny is real; the local trust path the populated attribute implies is not. A synced FIDO2 key in msDS-KeyCredentialLink is inventory, not a credential your domain controllers can do anything with, and Cloud Kerberos Trust remains the only road from a passkey to an on-premises Kerberos ticket.

The practical takeaways are unglamorous but useful. Plan outage behavior around what actually carries the load — hmac-secret cached sign-in, existing ticket lifetimes, and an NTLM fallback you should verify rather than assume. And if you audit for shadow credentials, learn what the legitimate Entra Connect writes look like first, because the attribute is now busier than most detection guidance assumes. None of this required anything beyond a test user, a security key, and a healthy distrust of FAQ pages.

Related Posts

• Essential Conditional Access Policies for Microsoft 365 — the policy layer that should sit in front of any passwordless rollout, including phishing-resistant MFA for admins.
• Detecting Kerberoasting with Windows Event ID 4769 — the same on-premises Kerberos auditing surface this post's Event ID 5136 detection lives next to.
• Migrating AzureAD and MSOnline PowerShell to Microsoft Graph — the tooling shift you will be living in while managing authentication methods and hybrid identity.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.