All-or-Nothing Teams CA Is Dead. In November, Conditional Access Drops to the Meeting.

The CFO joins the board call from an airport lounge, on a personal iPad, over hotel-grade Wi-Fi. Your Conditional Access policy has two options: force compliant-device on every Teams meeting in the tenant — including the daily standup and the 200-person all-hands — or force it on none. You picked none, because the help desk revolt wasn’t worth it. So the CFO walks into the most sensitive meeting of the quarter on an unmanaged device, and your CA policy watches it happen.

That trade-off is what’s ending.

November 2026: the roadmap date that changes the blast radius

Microsoft 365 Roadmap item 571879 lists general availability for per-meeting Conditional Access in November 2026. Until then, CA for Teams is scoped at the application level — you target the Teams and associated Microsoft 365 service apps, and the grant controls apply to the app’s entire surface. There is no built-in seam between “join a routine meeting” and “join the M&A war room.” The policy can’t tell them apart, so neither can you.

From 1 policy over everything to 1 policy over a subset

The shift is scoping, not new grant controls. You still get the same enforcement primitives you have today — require compliant device, require MFA, block from unmanaged locations, session controls. What changes is the target: instead of the control landing on all Teams meeting traffic, it lands on a defined set of meetings.

The roadmap doesn’t spell out the targeting UX in full, so I’ll be honest about what’s confirmed versus what’s inference. The existing mechanism for meeting-level policy in Teams is the sensitivity label applied to a meeting (via Teams Premium meeting templates and custom policies). That is the only per-meeting hook Microsoft already ships, and it’s the logical anchor for per-meeting CA. Expect the flow to be: label or template marks the meeting sensitive → CA policy is authored in Entra and evaluated when a participant tries to join that meeting. If the GA build introduces a different selector — organiser attribute, explicit meeting ID — treat this paragraph as a prediction, not gospel.

2 licences, and you’ll likely need both

This will almost certainly need both sides of the house. Conditional Access already requires Entra ID P1 at minimum (P2 for risk-based conditions). If the targeting relies on sensitivity labels—the most likely mechanism—then the per-meeting labelling and template machinery lives in Teams Premium. Skip either and you get half a feature: P1 without Teams Premium gives you tenant-wide CA with no meeting seam; Teams Premium without CA gives you sensitivity labels that lock down recording and copy but can’t enforce a compliant device at the door. Expect to budget for the pair.

Where it lives: two admin centres, one policy

Authoring stays in the Entra admin center under Protection → Conditional Access. The meeting-selection surface — labels, templates, sensitive-meeting policies — lives in the Teams admin center under Meetings. That split is the part that bites in six months: the security team owns the CA policy, the collaboration team owns the labels, and if those two teams don’t talk, you ship a control that never fires because nobody applied the label.

Before you build anything, inventory what already targets Teams. Read-only, paginated, no surprises:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome
​
try {
    # Get-MgIdentityConditionalAccessPolicy handles paging automatically with -All
    $policies = Get-MgIdentityConditionalAccessPolicy -All -ErrorAction Stop
}
catch {
    Write-Error "Failed to read CA policies: $($_.Exception.Message)"
    return
}
​
# Teams / M365 service app IDs commonly seen in CA include:
#   cc15fd57-2c6c-4117-a88c-83b1d56b4bbe  (Teams)
$teamsApps = @('cc15fd57-2c6c-4117-a88c-83b1d56b4bbe')
​
$policies |
    Where-Object { $_.Conditions.Applications.IncludeApplications |
        Where-Object { $_ -in $teamsApps -or $_ -eq 'All' } } |
    Select-Object DisplayName, State,
        @{n='Grants';e={ $_.GrantControls.BuiltInControls -join ', ' }} |
    Format-Table -AutoSize

When you do author the new per-meeting policy, keep it in report-only first and never pipe a live query straight into a create. Stage the intent, review it, then act:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Dry-run by default. Flip -WhatIf off only after review.
param([switch]$Apply)
​
$body = @{
    displayName = 'CA - Sensitive Meetings - Require Compliant Device'
    state       = 'enabledForReportingButNotEnforced'   # report-only first
    conditions  = @{ applications = @{ includeApplications = @('cc15fd57-2c6c-4117-a88c-83b1d56b4bbe') } }
    grantControls = @{ operator = 'OR'; builtInControls = @('compliantDevice') }
}
​
if ($Apply) {
    try   { New-MgIdentityConditionalAccessPolicy -BodyParameter $body -ErrorAction Stop }
    catch { Write-Error "Create failed: $($_.Exception.Message)" }
}
else {
    Write-Host '[WhatIf] Would create policy:' -ForegroundColor Yellow
    $body | ConvertTo-Json -Depth 6
}

The failure mode nobody puts on the slide

When a participant fails the grant, they don’t get into the meeting — same denial or upgrade prompt CA throws for any app today (get compliant, do MFA, or you’re out). That part works. The quieter risk is the inverse: a policy that only protects labelled meetings protects nothing the day an organiser forgets the label, or copies a meeting link from an old invite that predates your rollout. Tenant-wide CA was blunt, but it never had an off-by-default gap you could walk a board call through.

Per-meeting CA is the right fix for real friction. Just don’t mistake a narrower control for a stronger one — you’ve traded a policy that always fires for a policy that fires only when your labelling holds. Audit the labelling like it’s the control. Because now it is.