Two way synchronisation means identity data moves in both directions between Active Directory and connected applications. User profiles, users, and groups can be updated in the directory and reflected in SaaS apps, while selected application changes can also flow back, reducing drift and keeping access records current.
Expanded Definition
Two way synchronisation is an identity provisioning pattern in which changes can move from a directory to connected applications and, in selected cases, back again. The core idea is bidirectional consistency: one system does not remain the only source of truth for every field.
In practice, the boundary matters. Most deployments synchronise a limited set of attributes, such as display name, department, group membership, or account status, while treating sensitive fields, entitlements, and privileged changes more carefully. That distinction prevents a sync engine from becoming an uncontrolled write path into every application record. The term is often used alongside directory integration, but it is not the same as generic replication, single sign-on, or full master-data synchronisation.
For identity operations, the main benefit is reduced drift. For example, if a user is renamed in one system or a group changes in the directory, the change can be reflected downstream without waiting for a manual update. The practical tradeoff is that bidirectional flows require stronger rules about ownership, conflict handling, and which system wins when the same attribute changes in both places.
Examples and Use Cases
Two way synchronisation shows up wherever identity records need to stay aligned across directory and SaaS environments:
- A directory updates a user’s department or group membership, and the change appears in downstream applications that use that information for access or routing.
- An application-managed profile field, such as a preferred name or local account label, is written back to the directory so support teams do not work from stale records.
- A user disablement in the directory is reflected in connected apps to reduce the chance that access lingers after offboarding.
- A cloud service sends limited profile updates back to the directory, while the directory remains authoritative for core identity attributes.
The useful pattern is selective, not total. Teams normally choose a small set of fields that can safely move in both directions and keep security-sensitive values one-way or manually governed. That restraint avoids circular updates and makes it easier to explain where the authoritative record lives for each attribute.
Security Implications
Misconfigured two way synchronisation can create silent drift, overwrite trusted directory data, or amplify mistakes across many connected systems. Because updates travel in both directions, a bad value is not just copied once, it can be propagated back into the source record and then fanned out again.
That creates several concrete failure modes. Conflicting edits can cause data churn, access records can become inconsistent, and account status changes may not land everywhere at the same time. In identity workflows, even a short delay or mismatch can matter if an application keeps a session alive after the directory says access should be removed. The operational symptom is often not a dramatic outage, but a slow spread of stale or contradictory identity records.
When synchronisation rules are too broad, the blast radius grows quickly. A single malformed attribute, bad mapping, or unintended writeback can affect many users and groups at once. A practical indicator of trouble is repeated manual correction of the same field in multiple systems, which usually means the authority model is unclear.
Security, Operational and Governance Implications
Two way synchronisation is really a governance decision about authority, not just a technical connector. Teams need to decide which system owns each field, which changes are allowed to flow back, and how conflicts are resolved when records disagree.
That matters because identity data is used for provisioning, access review, deprovisioning, and audit evidence. If those records are inconsistent, downstream controls become harder to trust. In higher-risk environments, the design should be narrow enough that a sync failure is recoverable and visible, rather than a hidden path for accidental data propagation.
Practitioners should also be clear about lifecycle impact. Bidirectional sync can make onboarding and offboarding faster, but only if the rules are explicit and monitored. Without that discipline, the same mechanism that reduces manual work can also make errors harder to detect.
Risk and Threat Considerations
Two way synchronisation increases exposure when a trust relationship is allowed to write identity data back into a more authoritative directory. The main risk is not just stale data, but uncontrolled propagation of bad or malicious changes across multiple systems.
Failure mechanism: A mapping error, compromised connected application, or overbroad writeback rule can inject incorrect profile data, group membership, or account state into the directory, then redistribute that error to every linked application.
Impact: Access can be granted or revoked incorrectly, audit trails can become unreliable, and remediation becomes slower because the incorrect record may exist in more than one place at once.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Cybersecurity Governance | Two way synchronisation is a governance choice about identity-data ownership and control boundaries. |
| Recommendation — Define ownership for each synchronised attribute and approve bidirectional write rules. | ||
| CIS Controls v8 | 5 — Account Management | The term directly affects how user and group records stay current across systems. |
| Recommendation — Keep account and group changes synchronised so stale access is removed promptly. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Bidirectional identity data flows affect how trusted identity attributes are maintained. |
| Recommendation — Preserve authoritative identity attributes and restrict which fields may write back. | ||
Practitioner Guidance
Governance implication: Treat each synchronised attribute as a controlled data flow with an owner, an allowed direction, and a clear conflict rule. If those three pieces are not documented, the sync design is usually too permissive for reliable operations.
What to watch for: Repeated manual fixes, unexpected writeback behaviour, and identity fields that change in more than one system are signs that the sync boundary is too loose. Tighten the field set before the drift becomes systemic.
