Entra ID: tradeoffs to consider before connecting

PhishSpot can connect to Microsoft Entra ID (formerly Azure AD) to pull users and groups directly from your directory — see Chapter 25 Directory Sync for how. We support the integration, customers use it in production, and it works as documented.

This chapter exists because, for most organisations, we don’t think you should turn it on. The decision to grant directory-read scopes to a third-party SaaS is not a small one, and the convenience benefit is smaller than it looks once you account for the operational, security and compliance work it actually creates. The simpler alternative — quarterly CSV import — meets every realistic need of a phishing-simulation program at a fraction of the risk.

Read this before you click Connect to Microsoft. If you’ve already connected, read it before your next OAuth-grant review.

Default recommendation: do not connect Entra ID. Use CSV import from your HR system instead — see Chapter 5 Contacts and the bulk operations described in §5.6.
Three reasons in one breath: (1) the OAuth grant expands your attack surface by giving PhishSpot read access to your whole directory; (2) the integration couples your phishing program to Microsoft’s availability and your tenant’s policy decisions; (3) a phishing-simulation platform that trains employees to be suspicious of Microsoft-themed prompts shouldn’t itself be a Microsoft-themed prompt.
If you connect anyway: scope-review with your security team, register the processing with your DPO, time-box the OAuth grant and re-audit every six months. See §28.9.

28.2 What connecting Entra actually grants

The Entra connection in PhishSpot requests three Microsoft Graph scopes during admin consent:

User.Read.All — read the full user object for every account in your tenant.
Group.Read.All — read every security and Microsoft 365 group definition.
Directory.Read.All — read group memberships and organisation-wide directory data.

PhishSpot uses a small slice of this — email, first/last name, job title, department, location, telephone, the accountEnabled flag and group membership. It ignores the rest. But the scope is read everything: mobile phone, manager chain, licence assignments, mailbox settings, sign-in metadata, and the dozens of other attributes Entra surfaces for every user. The OAuth token PhishSpot stores after admin consent can fetch any of those fields, at any time, until you revoke it.

CSV import inverts this. You choose which columns to export from your HR system (first_name, last_name, email, department, title). Nothing else reaches PhishSpot — not because we’d refuse it, but because you never sent it.

This is the data minimization principle in GDPR Article 5(1)(c): personal data shall be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.” Granting Directory.Read.All for the purpose “run phishing simulations” is, on the face of it, hard to defend.

28.3 Security exposure

Three sub-arguments stack here.

The OAuth token expands your attack surface. PhishSpot stores a tenant-scoped Microsoft Graph token in its database. If PhishSpot is compromised — by a vulnerability in our code, a misconfigured cloud resource, a privileged-user mistake on our side — the attacker walks away with read-only directory access to your organisation. Before you connected, your directory was guarded by your own security perimeter. After, it’s guarded by ours too. You’ve doubled the number of organisations that need to stay secure for your directory to stay private.

The phishing-simulation irony. The whole point of PhishSpot is to teach employees to be suspicious of unexpected Microsoft prompts: the “Your password expires today” email, the “Click here to view a shared document on OneDrive” link, the surprise sign-in screen. By prompting users for SSO via Microsoft to access our platform, we train them in the opposite direction — that an MS-branded sign-in prompt, in the context of phishspot.com, is normal and expected. We have built the trojan horse our own training warns against. (This irony applies more strongly to Chapter 24 SSO with Microsoft 365; the same principle is relevant here because Entra integration and SSO share the same OAuth surface.)

The audit trail outlives the integration. When you grant admin consent to PhishSpot, the OAuth grant is recorded in your Entra audit log forever. Disconnecting later doesn’t delete that record. Five years from now, a new compliance auditor asks “why did this organisation grant Directory.Read.All to a third-party phishing vendor?” — and you, or your successor, has to explain.

28.4 Operational coupling

When you depend on a CSV file, you depend on a CSV file. When you depend on Entra sync, you depend on:

Microsoft Graph availability. A Graph outage — even a partial one — degrades or halts your sync. PhishSpot retries, but if the outage spans multiple days, your contact list drifts away from reality.
Conditional Access policies. Your tenant’s CA policies can silently block PhishSpot’s daemon flow. The next scheduled sync fails with an opaque error, but you don’t see it until the next time you open the integration page — which, for most admins, is “when something looks broken.”
Microsoft Graph schema changes. Microsoft updates the Graph API on its own cadence. A field rename, a deprecation, a permission re-mapping — and our sync logic has to adapt. We do that work, but the gap between “Microsoft ships the change” and “PhishSpot ships the fix” can be days.
Token lifetime and refresh. App tokens expire. We refresh them. Most of the time. When a refresh fails — admin password rotated, conditional access tightened, app marked as risky in MDM — your sync goes dark.

CSV has none of these failure modes. You upload, the data is loaded, and the only thing that ever changes is when you upload a new file.

We already mentioned GDPR Article 5(1)(c) in §28.2. There’s more.

Lawful basis. Article 6 requires you to have a lawful basis for processing personal data. “Legitimate interest” is the usual basis for phishing simulation — but legitimate interest requires a balancing test, and “we pulled the whole directory because it was convenient” doesn’t survive balancing when “we pulled the five fields we needed via CSV” was right there.
Record of processing activities (Article 30). Connecting Entra to PhishSpot is a new processing activity, with a new data flow, new sub-processor, new retention question. It belongs in your RoPA. CSV imports usually fold into an existing “phishing simulation” RoPA entry; Entra adds a fresh one.
DPO review. In most EU and UK organisations, granting Directory.Read.All to a SaaS vendor triggers a Data Protection Impact Assessment under Article 35. That’s weeks of process, often months. CSV import, with the same data subjects, often doesn’t trigger a DPIA at all — the data scope is narrower and the sub-processor relationship is simpler.

28.6 The hidden admin cost

The pitch for Entra sync is “set it once, forget it.” The reality is more work.

Global Administrator must consent. This is one or two people in most orgs — and their calendars are full.
DPO and legal review of the integration, RoPA entry, DPIA (sometimes).
Conditional Access policy carve-outs, if your defaults block app-only flows.
Quarterly audit of OAuth grants in the tenant (good security hygiene).
Re-consent when Microsoft renames scopes or requires updated app registrations.
Incident response when sync silently fails for a week and the next campaign targets ex-employees.

Versus the CSV alternative: any admin exports a five-column CSV from the HR system once a quarter, uploads it, done. No global-admin involvement, no DPO call, no audit follow-up. The “saved time” of Entra automation is mostly an illusion once you count the work it generates.

28.7 The simulation-program irony, in detail

This argument deserves its own section because it’s the one PhishSpot-specific reason that doesn’t apply to other SaaS integrations.

A successful awareness program teaches employees a few reflexes:

An unexpected Microsoft-branded sign-in prompt deserves a second look.
A “consent to grant this app access to your account” screen is something to read before clicking.
A prompt that arrives via email and asks for credentials is presumed hostile until verified.

PhishSpot’s Entra integration and Microsoft 365 SSO contradict each of these reflexes in our own UX:

We send users a Microsoft sign-in prompt at platform.phishspot.com/users/sign_in. They click it, complete MFA, and the “trust the Microsoft prompt in this context” reflex strengthens.
We ask the Global Administrator to click through a Microsoft consent screen granting our app Directory.Read.All. The reflex we want — “read this screen, question this scope” — is in tension with the integration we’re asking them to complete.

The result is an employee population that’s better trained for the simulations we send, but slightly worse trained for the real attacks they’re supposed to be defended against. The training transfers less well to “an unfamiliar MS-themed prompt outside PhishSpot” because we made one inside PhishSpot familiar.

This isn’t a fatal flaw — most awareness programs accept some imperfection — but it’s a reason to default to the simpler integration path that doesn’t produce the contradiction.

For nearly every organisation we work with, the right path is:

CSV import via Chapter 5 Contacts. Pick the columns you actually need (first_name, last_name, email, department, title, groups). Export from your HR system or Active Directory via PowerShell. Upload through the PhishSpot UI.
Quarterly refresh. Re-export and re-import once a quarter, or after major org changes (large hiring waves, reorganisations, M&A). The bulk operations in §5.6 handle removals.
Group membership in the CSV. PhishSpot accepts a comma-separated groups column — same outcome as Entra sync’s group mirroring, without the sync.
Risk scoring still works. Risk score is computed by PhishSpot from campaign results, not from Entra. Switching off Entra sync changes nothing about how risk score behaves.

This path covers 95% of phishing-simulation needs. It’s the path our long-running customers use even when their tenants are perfectly capable of supporting Entra sync.

28.9 If you connect anyway

We support Entra sync. Customers connect it. Sometimes there are genuine reasons: an organisation of 5,000+ employees where quarterly CSV doesn’t track org changes fast enough, a regulated environment where IT mandates directory-driven onboarding for all SaaS, a phased rollout where the simulation program is one of many tools sharing the same Entra pipeline.

If you decide to connect Entra ID, do it deliberately:

Scope review with security. Have your security team confirm User.Read.All / Group.Read.All / Directory.Read.All are acceptable under your vendor risk framework.
Time-box the OAuth grant. Set a calendar reminder to review the grant every six months. If you’ve stopped using sync, revoke.
Register processing. Add an entry to your RoPA. If you operate in the EU/UK and your DPO requires one, complete a DPIA.
Monitor sync health. The activity log in §25.6 is the only signal of degradation. Configure your operations team to check it after every scheduled run, or set up a webhook on a contact.updated quota.
Keep CSV ready. Have a current CSV export available for the day you want to disconnect — onboarding new contacts from CSV after Entra is gone is easier if you’ve kept the file.

Then proceed to Chapter 25 Directory Sync for the technical instructions.

28.10 Cross-references

Chapter 5 Contacts — the CSV import path we recommend instead.
Chapter 25 Directory Sync — technical instructions for the Entra integration this chapter argues against.
Chapter 24 SSO with Microsoft 365 — separate decision from directory sync; the simulation-irony argument in §28.7 applies to SSO too.
GDPR Article 5 — data minimization principle in EU law.

The same arguments apply to any future Google Workspace directory sync we might offer. They are not arguments against Microsoft as a vendor — they are arguments against OAuth-based directory sync between two unrelated SaaS products in general, and against the specific mismatch between phishing-simulation training and tight Microsoft integration in particular.