The change is small, but it matters for security. To see why, it helps to know what those two entries do and how attackers have used them.
What the roadmap says
According to the roadmap record:
- The feature: Outlook folder sharing will respect organizational restrictions on the Default and Anonymous permissions.
- What users see: If the restrictions are enabled, users can't change either setting.
- What stays the same: Permissions given directly to individual users are not affected.
- Status: In development.
- Product and platforms: Outlook, on Desktop and Web. The item is tagged #newoutlookforwindows.
- Release phase: General Availability, in the Worldwide (Standard Multi-Tenant) cloud.
- Estimated GA: January 2027.
The usual caveat applies. Microsoft says roadmap dates are estimates, all information can change, and entries may be removed once a feature ships, is canceled, or is postponed. Treat January 2027 as a target, not a promise.
In short: this is a planned lock on two specific permission entries. It does not shut off folder sharing.
Default and Anonymous: the two entries most people never notice
Open the permissions dialog on almost any Outlook mail folder and you'll see two entries that nobody added on purpose. One university IT guide describes them this way: Default (aka "People in my organization" or "My Organization") = everyone in our organization who is signed in (authenticated), while Anonymous = people outside the organization (not signed in).
The safe baseline is simple. For mail folders such as Inbox and Sent Items, that guide recommends Default = None, Anonymous = None. Calendars usually differ, with Default = Free/Busy, Anonymous = None.
The risk comes from how much these entries cover. Anonymous is especially broad. In a Microsoft Q&A thread, a responder explained that if you set Anonymous to one of the folder permissions, any user outside your organization (if they know or you publicly shared the URL of the shared folders) they can access the folder based on the permission level you set. The same thread notes that Microsoft doesn't recommend removing the Default or the Anonymous permission from an Outlook folder. So the right move is to keep these entries locked down at None, not to delete them.
Some older campus help pages actually taught users to open these entries up. One guide for sharing a folder "with everyone" tells users to click Default, then change the Permission Level to Reviewer, and then do the same for Anonymous. That may have been fine on a contained on-premises Exchange server. In a multi-tenant cloud with phishing-compromised accounts, it is much harder to defend.
In short: Default and Anonymous are broad entries that cover everyone in the organization or everyone outside it. A single wrong change to either one exposes a folder to far more people than a named-user grant would.
Why security teams care
This isn't only a theoretical problem. The U.S. Cybersecurity and Infrastructure Security Agency's ScubaGear project, which assesses Microsoft 365 security configurations, has an open proposal on GitHub to add a policy that checks for users in Exchange Online that have Default or Anonymous permissions set on their mailboxes. The reasoning is direct: when the permission named Default is set, it allows widespread access to a victim user's mailbox by any member of the organization.
The proposal describes an attack built on this behavior. It walks through signing into Outlook on the web, opening the Inbox's Sharing and Permissions dialog, selecting Default, and setting it to Reviewer. Anyone else in the tenant can then read that Inbox. As the write-up notes, the adversary needs an email account in the victim's organization. Phished credentials for any low-privilege mailbox would work.
Here's the scenario. An attacker briefly controls an executive's session, changes one dropdown, and leaves. From then on they can read that executive's mail from a second compromised account. Mailbox audit reviews built around delegate access or forwarding rules can easily miss it.
That is the threat this roadmap feature addresses. If users can't change Default or Anonymous, a hijacked session can't quietly open up a folder this way either.
In short: a Default permission change is a known persistence and data-access technique. Removing users' ability to make that change reduces the attack surface.
What does not change
The scope matters here, and the roadmap is specific:
- Named-user grants keep working. A manager can still give an assistant Reviewer or Editor on a project folder.
- Folder sharing is not disabled. The restriction covers two entries only.
- No automatic cleanup is promised. The roadmap doesn't say existing Default or Anonymous permissions will be reset, audited, or removed. If a folder was opened up last year, nothing in the announcement says this feature will close it.
That last point is easy to miss. Several important details are still unpublished:
- The admin setting that turns the restriction on, and where it lives.
- Whether it affects permissions that already exist.
- Whether admins can still change these entries through PowerShell or another management tool.
- Whether it covers calendars, contacts, and other folder types as well as mail folders.
- Whether classic Outlook, new Outlook for Windows, and Outlook on the web will behave identically. The roadmap lists only "Desktop" and "Web."
It's also worth separating this from a related control. The ScubaGear discussion quotes an earlier Microsoft change in which a Cloud Policy setting called "Turn off sharing" will disable the ability for users to share or edit folder permissions with individual users in Microsoft Outlook on the web and new Microsoft Outlook for Window desktops. That setting targets individual-user sharing. The new roadmap item works the other way: it leaves individual sharing alone and locks the broad entries. Microsoft hasn't said whether the two share any underlying mechanism, and you shouldn't assume they do.
The new feature also isn't the same as Exchange Online sharing policies. Microsoft documents those as controls over how your users share their calendars with people outside your organization. They cover external calendar sharing by domain and level of detail, not mailbox folder permission entries in general.
In short: expect a narrow guardrail, not a cleanup tool. Microsoft hasn't yet said how it will be configured or how far it reaches.
What admins can do before January 2027
There's no reason to wait for GA to find out whether your tenant already has exposed folders. Based on general Exchange Online administration practice (not on anything in the roadmap item), these steps make sense:
- Audit current state. Use Exchange Online PowerShell to list mailbox folder permissions and flag any Default or Anonymous entry set to something other than None on mail folders, or other than Free/Busy-style access on calendars. CISA's ScubaGear proposal is a good reference for why this check is worth automating.
- Look at high-value mailboxes first. Executives, finance, HR, and legal are the obvious targets for the Default-Reviewer technique.
- Find out why before you fix. Some departments may have opened Default on purpose, such as a team calendar or a shared reference folder. Move those to explicit named-user or group grants so nothing breaks when the lock arrives.
- Update internal help pages. Retire any guidance that tells users to change Default or Anonymous to share a folder. Once the restriction is on, those instructions will fail, and your help desk will get the calls.
- Watch the roadmap and Message Center. The setting name and configuration steps should appear closer to rollout.
In short: audit now and move legitimate use cases to named grants, so turning on the restriction later is uneventful.
What users will notice
For most people, nothing changes. Microsoft's documented process for sharing a folder with a colleague in new Outlook and Outlook on the web stays the same: right-click the folder, choose Sharing and permissions, add the person, pick a permission level, and confirm. Microsoft's support documentation describes the permission levels as running from Owner-level control down to Reviewer (read only), Contributor (create only), and None.
The difference appears only if someone selects Default or Anonymous in that dialog after their organization has enabled the restriction. They won't be able to change it. If you hit that wall, it's the policy working as intended, not a bug. Share with the specific people who need access instead.
One related housekeeping point from Microsoft's documentation: when you share a subfolder, Outlook may add a minimal "Folder visible" permission to parent folders so the recipient can navigate to it. Removing the subfolder share later doesn't automatically remove those parent-folder entries. They don't expose content, but anyone who wants a fully clean permissions list should remove them by hand.
The bigger picture
This is a sensible, low-risk default. For years, two of the most dangerous permissions in Exchange have been fully editable by every end user, in a dialog most people don't understand. Locking them while leaving named-user sharing alone is the right balance. It blocks a documented attack technique without getting in the way of how people actually work together.
The open questions are about detail. Will admins be able to enforce the restriction separately for mail folders and calendars? Will it cover existing exposures or only new changes? How will classic Outlook behave? Until Microsoft publishes the configuration documentation, the safest approach is to treat this as a guardrail on future changes and start auditing your existing permissions now.