Hard Matching

What Hard Matching Does in Hybrid Identity

Hard matching is the mechanism that gives a cloud directory a stable pointer back to the authoritative on-premises identity object. That binding is what preserves continuity during synchronisation, account moves, and tenant integration work, but it also makes the source anchor a high-value control point because changing it can redirect authority.

In practice, hard matching is less about “linking two accounts” in a cosmetic sense and more about preserving identity lineage. The cloud object inherits continuity from the on-premises object, so the security question becomes whether the anchor remains immutable, trustworthy, and owned by the right administration path.

Why Stable Source Anchors Matter

The core value of hard matching is consistency. A durable anchor prevents duplicate cloud identities, reduces drift between directories, and helps identity operations recognise that two records represent the same principal. In hybrid environments, that continuity is essential for mail flow, access continuity, and lifecycle management.

The same stability is also what makes the mechanism sensitive. If the anchor can be altered, an attacker or careless operator may be able to bind a cloud identity to a different on-premises object, which can create confusion about ownership and authority. The security significance is not the attribute itself, but the authority it conveys once the directory trusts it.

How Hard Matching Is Used and Misused

Administrators use hard matching during migrations, rehydration, directory consolidation, and recovery from sync issues when the cloud object already exists and needs to be tied back to the correct source record. The intended outcome is a clean, deterministic relationship between the authoritative source and the cloud representation.

Misuse typically appears when matching attributes are treated as ordinary metadata rather than privileged identity-binding data. That is where takeover risk emerges: if someone can change the anchor or influence the sync process, they may be able to transfer the cloud-side relationship to a different source identity and inherit its standing.

Operational Safeguards for Identity Binding

Hard matching should be treated as a governed identity-control operation, not a convenience setting. The attributes used for binding need tight change control, and the teams that administer directory synchronisation should be able to distinguish legitimate lifecycle work from suspicious object re-binding.

• Keep source-anchor attributes protected from routine edits.
• Limit who can perform sync and directory-binding operations.
• Review reconciliation events for unexpected object changes or duplicate-resolution activity.
• Validate that the authoritative source object is the one actually being bound before changes are made.

In a hybrid estate, the safest assumption is that matching data is part of the access-control plane, because it can shape which identity the cloud directory believes it is trusting.

Risk and Threat Considerations

Hard matching creates a concentrated trust point in hybrid identity. If the matching attribute, sync process, or administrative path is compromised, the attacker may be able to rebind an existing cloud identity to a different on-premises object and inherit that identity’s continuity, permissions, or trust relationships.

Failure mechanism: The source anchor is changed, spoofed, or manipulated so the directory accepts the wrong authoritative binding and treats one identity as another.

Impact: The result can be unauthorised authority transfer, account confusion, persistence across identity layers, or loss of confidence in which object truly owns access and lifecycle state.

Practitioner Guidance

Why practitioners should care: Hard matching is one of those hybrid controls that looks administrative but can have direct security consequences if its binding attributes are writable by the wrong people. Treat it as a privileged identity operation with explicit ownership.

Common misunderstanding: Teams often focus on whether synchronisation “works” and overlook whether the binding is trustworthy. A successful match is not sufficient if the mechanism that created it can be abused to redirect authority later.

Practitioner takeaway: The key design goal is not just continuity, but continuity that cannot be quietly reassigned.

Related resources from NHI Mgmt Group

• Guide: Microsoft Entra Connect and Cloud Sync Hardening Guide
• What is the difference between hard matching and soft matching in identity sync?
• What breaks when hard matching can remap a synchronized Entra ID account?
• How do you prevent object takeover through soft and hard matching in Microsoft Entra Connect sync?
• What is the impact of using hard-coded credentials on security?