Why did a cloud-only Microsoft 365 user suddenly become marked as synced from on-premises AD?

I would also investigate whether the account was ever part of an earlier migration. An old synchronization server, a temporary Entra Connect installation, or a restored/recreated user could have left the object with synchronization metadata. If an on-premises object later appeared with matching identifiers, the service could have associated the cloud object through soft matching.

The fact that most other users are cloud-only does not rule this out; a single object can be affected by a match or an administrative change without the whole tenant being synchronized.

The password-reset error is a symptom of the account being treated as synchronized, not evidence that password writeback suddenly turned itself off. Once an account is marked as managed from on-premises, password changes are expected to go through the local directory and writeback configuration.

If the account is supposed to remain cloud-managed, changing its on-premises sync behavior back to cloud-managed is the appropriate direction. Verify the result with Microsoft Graph and then test a password reset. Keep in mind that changing that flag does not necessarily erase historical on-premises metadata, so seeing those fields afterward can be normal.

The audit trail is the key here. Portal status pages can show the current state and a last-sync timestamp, but they usually will not explain why the state changed. Search directory audit and provisioning logs for the user object and inspect the initiating actor, application, IP address, and modified properties. Also review administrative activity for changes to synchronization settings and permissions.

I would not assume an unexplained Microsoft-side automation event without those logs. If the logs do not identify the source, open a support case with the object ID and exact timestamps; Microsoft can sometimes correlate backend synchronization events that are not visible in the normal tenant views.

The most likely explanation is that some synchronization process or directory operation touched the account, even if nobody remembers setting one up. A previously synchronized object can retain its on-premises attributes after synchronization is disabled, so the old domain, OU, SID, and distinguished name do not prove that synchronization is currently active.

Check the tenant audit logs around the timestamp shown on the user. Look for changes to the account’s synchronization state, source anchor, immutable ID, on-premises attributes, and any application or service principal making the change. Also review Entra Connect or cloud synchronization configuration, including deleted or recently re-created agents. A soft match to an on-premises object is another possibility if the account’s sign-in address, proxy address, or other matching attributes appeared in AD.