The critical tier was mostly about who can reach your files at all. This is where the questions get harder and more interesting: what a link should default to, whether a guest may pass access on to someone you never met, which container a piece of work belongs in, and how long a departed employee’s files should outlive them. These are the items where I have watched two competent consultants reach different answers, so the reasoning matters more than the value.
Link defaults, which are the highest-leverage setting in the product
When somebody clicks Share, one setting decides what they get offered first, and almost nobody clicks past it. That makes the default link type the single most consequential choice in the sharing configuration, far more so than the ceiling settings the critical tier covered, because the ceiling governs what is possible and this governs what actually happens ten thousand times a year.
Set it to organisation-scoped, and set the default permission to view rather than edit. Microsoft’s own hardening guidance says the same. The federal baseline goes further and requires specific-people with view only, which is defensible and does add friction, because a link scoped to named people breaks the moment somebody forwards it, which is exactly what it is for and exactly what generates the support call.
One honest gap: Microsoft no longer documents what the factory default actually is. The settings page describes the three options and never says which one ships. So read your tenant rather than assuming it, and be aware of one interaction that catches people out: if you set the default to anonymous but the site only permits signed-in guests, the offered default silently becomes organisation-scoped instead. The setting you configured is not always the setting a user sees.
Expiry on anonymous links is the companion control, and it is worth restating that no default expiry exists. Unset means never. The federal ceiling is thirty days and I would use it. Note the mechanic when you change it later: existing links keep their expiry if the new setting is longer, and are pulled in if it is shorter. So tightening the number reaches back and loosening it does not, which is the behaviour you want and the opposite of what most people expect.
Connect-SPOService -Url https://catsnackjack-admin.sharepoint.com
Get-SPOTenant | Format-List DefaultSharingLinkType,DefaultLinkPermission,
RequireAnonymousLinksExpireInDays,FileAnonymousLinkType,FolderAnonymousLinkType,
PreventExternalUsersFromResharingGuest resharing, and why I stop it
A guest with sufficient permission can share your content onward to people you have never heard of. That is not a bug, it is how permissions work, and it is also the mechanism by which a document sent to one accountant ends up with their whole practice.
Prevent it. The reasoning is about where authority sits rather than about risk appetite: you decided to trust one external person, and resharing lets that person extend your trust decision on your behalf, silently, with no record you would notice. Whatever your posture on external sharing generally, the person making the decision should be someone in your organisation.
Verify rather than assume the current value. Microsoft’s description of the admin-centre checkbox is genuinely muddled about what the default is, and the cmdlet is clearer than the page, so read the tenant.
Containers: labels, lifecycle and the question nobody asks
Sensitivity labels applied to the container rather than the file are the most underused control in this product. A label on a team or a site can set its privacy, its external sharing capability and its unmanaged-device access in one object, which means the classification and the enforcement stop being two separate exercises that drift apart. Where an organisation has any classification scheme at all, container labels are how it becomes real rather than aspirational.
Group lifecycle is the other half. An expiration policy with owner renewal, a naming convention, and a decision about who may create groups at all. All three are unglamorous and all three are the difference between an estate you can reason about in three years and one nobody dares touch. Expiration needs a premium identity licence, which most estates running this baseline already have.
On creation restriction I am more cautious than most. Locking group creation to an approved set feels like governance and frequently produces a shadow estate instead, because the work still needs doing and people route around the control. I would rather have naming, expiry and ownership discipline on an open creation model than a locked one that pushes collaboration into personal OneDrive and consumer tools. Restrict creation where the organisation genuinely has a request process people will use, and not otherwise.
Which leads to the structural question this baseline should ask and most do not: when someone needs a place to put work, what should they be told to create? A team, a communication site, a group, a channel in an existing team, or nothing at all because it belongs in an existing space. Every estate I have inherited that was unnavigable got that way because nobody ever answered it, and no setting fixes it afterwards. Write down the answer and put it where people ask the question.
Device trust: sync, download and the unmanaged machine
Two controls, and they answer different questions. Restricting sync to domain-joined or compliant machines stops corporate documents landing on a laptop you cannot wipe. Blocking download from unmanaged devices lets somebody read a document in a browser without taking a copy away with them.
The second is the one worth applying selectively rather than everywhere, because it changes how the product feels. Scope it to the sites holding material that would actually matter, which in most organisations is finance, legal, HR and whatever the business considers its crown jewels. Applying it estate-wide is the reflex, and it is how you teach people that the compliant path is the slow path.
Worth knowing that the block-download capability, along with restricted access control and the site-level access reviews, comes from the advanced management add-on, and that add-on now arrives with any Copilot licence in the tenant. If somebody bought Copilot for a pilot group, these controls became available and nobody was told.
Teams: apps, meetings and one setting that should simply be off
App governance in Teams is three permission policies rather than one: Microsoft apps, third-party apps, and custom apps built in-house. The federal baseline requires all three to be restricted to an approved set, and that is a reasonable position for a regulated estate. For a commercial one, the honest position is that blanket third-party blocking generates a steady stream of exception requests and the exceptions get granted, so the control that survives is an allow list somebody actually maintains plus a request path with a named owner. Pick the version you will still be running next year.
Meeting policy has two items worth the argument. Recording should default off and be enabled deliberately, because a recording is a data object with retention consequences that the person clicking the button is not thinking about. And the lobby settings deserve reading rather than skimming: whether anonymous and dial-in participants are admitted automatically, whether internal people bypass, and whether dial-in callers can bypass, are three separate decisions and the defaults are not all what you would choose.
Then the easy one. Teams email integration, which lets anyone email a channel directly at a generated address, should be off. It is a mail endpoint with no sender authentication expectations, attached to a collaboration space, and almost nobody uses it deliberately. The federal baseline makes disabling it mandatory and I have never met an estate that missed it.
Third-party storage providers in Teams are the same argument as the mail client version in the previous wave and get the same answer: off, unless a named business process depends on one.
What happens to files when people leave
A departing employee’s OneDrive is retained for a configurable period after their account is deleted, and the default is not chosen with your organisation in mind. Set it against how long it actually takes your business to notice that something important lived in someone’s personal storage, which in my experience is considerably longer than anyone admits.
The better answer is upstream and it is not a setting. Work that matters should not be in personal storage in the first place, which loops back to the structural question above. The retention window is a safety net for a problem the estate’s design should be reducing, and treating it as the solution is how organisations end up with retention policies protecting a filing system nobody meant to build.
The recommended settings, in brief
| Domain | Setting | Set it to |
|---|---|---|
| External Trust | Default sharing link type | Organisation-scoped, permission view; read the tenant rather than assuming the factory value |
| External Trust | Anonymous link expiry | 30 days; no default exists, so unset means never |
| External Trust | Guest resharing | Prevented; the trust decision belongs to someone in your organisation |
| Tenant Governance | Container sensitivity labels | Applied, carrying privacy, external sharing and unmanaged-device access together |
| Tenant Governance | Group expiration and naming | Both configured, with owner renewal |
| Tenant Governance | Group creation restriction | Only where a request process exists that people will use |
| Tenant Governance | Where new work goes | Written down and published; no setting substitutes for the answer |
| Device Trust | Sync restriction | Domain-joined or compliant devices only |
| Device Trust | Block download on unmanaged devices | Scoped to the sites that warrant it, not estate-wide |
| External Trust | Teams app permission policies | All three restricted to an approved set, with a maintained request path |
| Data and Email | Meeting recording | Off by default, enabled deliberately |
| External Trust | Meeting lobby settings | All three decisions made explicitly rather than inherited |
| Data and Email | Teams email integration | Disabled |
| Data and Email | Third-party storage in Teams | Disabled unless a named process depends on it |
| Data and Email | OneDrive retention after deletion | Set against how long your business takes to notice, not the default |
The next article is the one I would read before any Copilot conversation: what oversharing actually is, why the tooling for fixing it is licensed by the thing you are trying to prepare for, and what to do first.
Best Practices
‹ Previous: [BP 3.1.1] Build Sheet: The Guest Account Inventory Before October
Next: [BP 3.3] Before Copilot: Fixing What Everyone Can Already See ›
