Entra ID contact sync best practices: the 10 rules every admin should follow

These are the ten rules that separate a contact-sync deployment that runs for years with zero drift from one that needs constant babysitting. They cover authentication, change detection, field minimization, and the compliance scaffolding auditors look for.

1. Certificate auth, not client secrets

App-only authentication to Microsoft Graph must use a certificate. Client secrets have shorter lifetimes, can’t be tied to HSMs, and are disabled by policy in many tenants. Generate with New-SelfSignedCertificate, rotate annually.

2. Exactly three Graph permissions — nothing more

User.Read.All, Group.Read.All, Contacts.ReadWrite. Every additional permission widens your blast radius in a breach and makes admin consent harder to get. Least privilege is not a slogan, it’s the whole point.

3. Write into the Contacts well-known folder

Create your sync folder as a child of contactFolders (the Contacts well-known folder), not as a direct child of MsgFolderRoot. Only the former is visible to Graph and syncs reliably to mobile devices. Legacy EWS scripts made this mistake; see the migration guide for cleanup.

4. Use delta queries, always

Full-scan sync doesn’t just waste API budget — at scale it’s the primary cause of 429 throttling. Both /users/delta and /users/{id}/contacts/delta give you change-only payloads. See the throttling deep-dive.

5. Use Open Extensions for stable identity

Don’t match contacts by email — emails change when people marry, get promoted, or move domains. Use a Graph Open Extension (CYNC uses com.itbaer.cync) to store the source user’s Entra ID object ID directly on the contact, then match on that.

6. Sync fewer fields than you think

Just because Graph exposes 60 fields on a user doesn’t mean you should sync all of them. Name, title, department, email, mobile, and business phone cover 95% of user needs. Extra fields = more payload, more drift, and more GDPR surface.

7. Document GDPR processing in your RoPA

In EU and UK deployments, syncing employee directory data to personal phones is a processing activity. It’s almost always legitimate-interest lawful — but document it. Record the purposes, categories, retention, and recipients in your Record of Processing Activities. Provide an opt-out for sensitive fields like private mobile numbers.

8. Scope the source filter tightly

Sync a specific Entra ID group (e.g. “All Staff”), not the entire tenant. Contractors, service accounts, shared mailboxes, and resource mailboxes should never end up as personal phone contacts. A group-based source is the simplest way to enforce this.

9. Monitor in the Windows Event Log, not via email

Emailed sync reports are the worst kind of noise — admins stop reading them within a month. Write structured sync results to the Windows Event Log and let your RMM/SIEM pick them up. Alert on errors, ignore the successes. CYNC does this by default.

10. Have a kill-switch

Something will eventually go wrong: a misconfigured group, a renamed OU, a user whose data was never meant to be shared. You need to be able to stop the sync and roll back the contacts inside 15 minutes. CYNC supports a “disable and revert” mode that removes previously-synced contacts using the Open Extension marker.

Summary

1. Certificate auth.
2. Three Graph permissions, no more.
3. Write into the Contacts well-known folder.
4. Delta queries always.
5. Open Extension for identity.
6. Minimum field set.
7. GDPR RoPA entry.
8. Scoped source group.
9. Event Log monitoring.
10. Documented kill-switch.

Implement these rules and contact sync becomes what it should be: boring, predictable infrastructure that survives audits and rotates under you without user-visible failures.