EwsAllowedAppIDs: what to set, and what happens if you don't
The allow list is the only thing that keeps an EWS application running past the October 2026 enforcement wave, and it only works in combination with EwsEnabled. Two settings, one org-level cmdlet, and a deadline on the far end the allow list does not move.
- $null · blankNever decided. Microsoft automatically changes this to
$falseon October 1, 2026 for any tenant that has not explicitly set$true. An allow list does not rescue this posture. - $trueEWS is enabled. Starting October 2026, only applications on the allowed app IDs list can call EWS —
$trueon its own no longer permits unrestricted access. - $falseEWS is disabled org-wide. The organisation-level setting overrides per-mailbox EWS settings, so this is the level the retirement acts on.
- Mar 31 → Apr 1Allow-listed applications work through March 31, 2027. April 1, 2027 is the hard deadline: no extensions, no exceptions, permanent removal, no re-enablement.
Set-OrganizationConfig -EwsEnabled:$true Set-OrganizationConfig -EwsAllowedAppIDs "<comma-separated Entra app client IDs>"
The values are Entra application (client) IDs. Read it back from the tenant afterwards — not from the change ticket that was supposed to set it — and pipe the output into deadlinescan tenant for a plain verdict.
A finding count of zero means no affected call sites were FOUND — not that you're unaffected.
Scan your code
Free, local, one command. Flags the sites with no Graph equivalent.
Get the scannerGet the scanner: email [email protected] and you'll get the source and a Windows binary by reply — the public repository is being prepared.
Microsoft pre-populates the allow list for customers who have not created one before September 2026, from each tenant's own EWS usage telemetry. It does not rescue a blank EwsEnabled, and it misses the job that only runs monthly. Microsoft first-party applications must be included if they appear in your usage reporting.