Microsoft Entra ID: How are user passwords stored and protected in transit?

Yes. The two compliance statements are technically correct based on the documented behavior of Microsoft Entra ID and Microsoft Entra Connect.

1. Passwords are not stored in plaintext in Microsoft Entra ID.
   • With password hash synchronization, the plain-text password is not exposed to password hash synchronization, to Microsoft Entra ID, or to associated services.
   • The original MD4 hash from on-premises Active Directory is not transmitted to Microsoft Entra ID.
   • Instead, the SHA256 hash of the original MD4 hash is transmitted.
   • Microsoft states this value cannot be decrypted and cannot be used for an on-premises pass-the-hash attack.
   • Microsoft also states that passwords are never sent to Microsoft Entra ID or stored there in clear text.
2. If Password Hash Synchronization (PHS) is used, the transmitted value is a derived hash value, not the password itself.
   • Microsoft Entra Connect obtains the on-premises password hash material from Active Directory.
   • The original MD4 hash is processed further, and the SHA256 hash of the original MD4 hash is what is transmitted to Microsoft Entra ID.
   • During sign-in, the entered password is run through the same MD4 + salt + PBKDF2 + HMAC-SHA256 process, and the result is compared with the value stored in Microsoft Entra ID.
   • The password hash value is never stored in SQL by the sync process; it is processed only in memory before being sent to Microsoft Entra ID.
3. Authentication and directory data transmitted over the network are protected by encryption.
   • Microsoft documents that customer-facing web services are secured with Transport Layer Security (TLS).
   • Microsoft also states that directory data in Microsoft Entra ID is signed and encrypted while in transit between datacenters.
   • For Microsoft Entra Domain Services password-hash-related flows, Microsoft documents encrypted transmission of the encrypted key material and encrypted data structure, and internal synchronization over an encrypted HTTP session.
4. Behavior differs by sign-in method.
   • PHS: Microsoft Entra ID stores a non-reversible password-derived value used for cloud authentication.
   • PTA: Microsoft Entra ID does not automatically fail over to PHS. PTA validates passwords by using on-premises software agents, so the authentication path differs from PHS.
   • Federation: Authentication is handed off to a separate trusted authentication system such as AD FS or a third-party federation system.
   • Microsoft also states that if switching from PHS to PTA, password hashes previously synchronized by PHS remain stored in Microsoft Entra ID.

For internal compliance wording, these statements are supported:

“User passwords are not stored in plaintext or in a reversibly encrypted form in Microsoft Entra ID, but are stored in a non-reversible form.”

“Authentication information transmitted over a network is protected through encrypted communication.”

A precise compliance-oriented summary:

• In Microsoft Entra ID cloud authentication with PHS, Microsoft Entra ID stores a non-reversible password-derived hash value, not the plaintext password.
• The original on-premises MD4 hash is not transmitted to Microsoft Entra ID; a SHA256 hash of that hash is transmitted instead.
• Microsoft documents TLS for customer-facing web services and states directory data is signed and encrypted in transit.
• The exact password handling path differs by authentication method: PHS stores a cloud-side derived hash, PTA validates through on-premises agents, and Federation delegates authentication to an external trusted identity system.

• Implement password hash synchronization with Microsoft Entra Connect Sync
• Microsoft Entra Connect user sign-in options
• Data protection considerations
• Microsoft Entra pass-through authentication: Frequently asked questions
• Implement password hash synchronization with Microsoft Entra Connect Sync