Container labels versus file labels: the 90% of Australian tenants doing it wrong

There are two kinds of sensitivity label in Microsoft Purview. File labels apply to a single file or email and travel with the content. Container labels apply to a SharePoint site, Microsoft 365 Group or Teams team and govern the container's behaviour — membership policy, sharing settings, default privacy, and crucially, whether unmanaged devices can access the content.

Frontrow audits Information Protection postures across Australian mid-market tenants. The single most common finding: file labels deployed and used (at whatever rate), container labels not deployed at all. The two are different controls solving different problems. Most tenants are running half the program.

Why file labels alone aren't enough

A file label travels with the file. If the file is exfiltrated, the encryption follows. If the file is forwarded as an email attachment, the label and its rights persist. This is the strength of file-level labelling — protection is bound to the data.

But labels only travel with files that are labelled. The Purview Activity Explorer tells the truth: in most tenants, manual labelling tops out at about 30 to 40 percent of new documents. The other 60 to 70 percent are unlabelled and travel without protection. The site they live in — the SharePoint site or Team — is fully shareable to anyone the site is shared with. An unlabelled file in a Confidential-content site is still confidential, and it leaves with whoever has access to the site.

Container labels close that gap. A container label on a SharePoint site can: block external sharing entirely; allow external sharing but only to specific domains; require unmanaged-device blocks at the container level; require all members to be on a managed device; force the underlying Microsoft 365 Group to private; set the default permissions for the site. The container governs the bulk behaviour. The file label governs the per-file specifics. You need both.

Why most tenants don't have container labels

Container labels require a tenant-level enablement step. The Microsoft Graph PowerShell sequence is documented but obscure. The default Purview labelling setup gets you file labels and not container labels — which is why most tenants stop at file labels. They didn't choose to skip container labels; they didn't realise they were available, or the consultant who set up the program didn't run the enablement step.

The other reason: container labels are most useful when they are applied at site creation. Retroactively labelling existing sites is straightforward but the value compounds when every new site picks a label at creation. Most tenants have not configured the Microsoft 365 Group creation policy to require label selection.

The fix

1. 1Enable container labels at the tenant level. The Microsoft Graph PowerShell sequence (Execute-AzureAdLabelSync, then enable EnableMIPLabels in Entra) is documented in Microsoft Learn. One-time step, fifteen minutes including reading.
2. 2Configure each label to govern container behaviour. For Confidential and above: external sharing disabled or restricted to allowlisted domains, unmanaged device download blocked, default site privacy = private, default permissions = members only. Highly Confidential / Restricted should additionally require the underlying Group be private and require all members on a managed device.
3. 3Apply container labels to existing SharePoint sites by sensitivity tier. The Frontrow approach is a one-pass review of every site — check usage, identify the highest-sensitivity content type the site holds, apply the corresponding container label. Most mid-market tenants have between 100 and 500 sites; the work is methodical but finite.
4. 4Configure the Microsoft 365 Group creation policy to require label selection at site creation. After this step, no new SharePoint site can be created without choosing a sensitivity label. Net-new coverage becomes 100 percent.
5. 5Pair with Conditional Access. The container label sets the requirement (for example, require unmanaged device block). The Conditional Access policy enforces it (for example, scope the unmanaged-device condition to the container label). The two controls combine to enforce the policy at the request layer rather than relying on SharePoint to refuse downloads.

What this looks like once it's running

After a container label rollout, sensitive SharePoint sites are physically incapable of being shared with the wrong audience. The 'oh, I didn't realise that file went out via the share link' incidents stop happening at the container layer rather than relying on user vigilance and DLP backstops. The audit trail (Purview Audit) shows that the container label was checked on every access attempt. The OAIC determination question "what reasonable steps did the organisation take to prevent this" has a defensible answer.

How Frontrow runs this as a managed service

Container label rollout is one of the standing modules in the Frontrow Managed Identity & Information Protection program. The retroactive label-application sweep is done once. Net-new coverage is enforced via the M365 Group creation policy. Quarterly review confirms drift hasn't occurred — labels haven't been removed, the EnableMIPLabels setting hasn't reverted, no new untagged sites have been created. The output is part of the quarterly Privacy Act 2026 alignment evidence pack.

If your tenant has file labels and not container labels — which is the case for nine in ten tenants Frontrow audits — that's the engagement. Email info@frontrow.email.