Among the security controls available in the cloud suite, Conditional Access is one of the most powerful, and it is the right place to begin a conversation about Teams access security. The core idea: rather than granting access to Teams unconditionally to any authenticated user, you impose conditions. Additional verification is required if the device isn't compliant. MFA is required if the user is signing in from an unusual location. Where the app is being reached from a personal device, restrict what they can do.
Conditional Access is configured in the identity service (formerly the cloud platform AD) rather than in the Teams Admin Center. Even so, it applies directly to Teams — and to every the cloud suite app — via the cloud app targeting mechanism.
How a Conditional Access Policy Is Structured
Three parts make up a Conditional Access policy: assignments (who this applies to, and under what conditions), target resources (which apps this applies to), and access controls (what happens once the conditions are met).
Assignments cover users/groups, cloud apps or actions, and conditions (client apps, sign-in risk, location, device platform). Target resources may be specific cloud apps (such as the cloud suite) or all cloud apps. Access controls either grant access (with or without MFA, device compliance, or other requirements) or block it.
Baseline Policy: MFA Required for Teams
This is where to start if you have no Conditional Access policies today. The single highest-ROI security control available is a policy that requires MFA for all users accessing the cloud suite apps (Teams included).
How to configure the policy:
- Users: All users, or begin with a pilot group
- Target: the cloud suite (covering Teams, Exchange, and the file service)
- Conditions: None (applied universally)
- Access control: Multi-factor authentication required
- Client apps: Cover desktop, mobile, and browser. A policy that includes only the browser leaves out the desktop client, which is how most people actually open Teams.
- Grant versus block: Favour granting access once the controls are satisfied. A block targeting "legacy authentication" is a separate policy and should not be merged into the Teams grant rule until both have been tested.
Before switching this on for all users, confirm that every user has registered an MFA method. Enable MFA enforcement before users have registered and you will lock them out. Registration can be driven ahead of enforcement by the vendor's MFA registration campaign (in the identity service > Identity > Overview > Users > MFA registration).
Policies Based on Device Compliance
A device compliance policy requires the device accessing Teams to be managed by the device management service and to meet a defined compliance standard (antivirus running, OS version current, encryption enabled, and so on).
Build a device compliance requirement into your Teams Conditional Access policy and access from unmanaged personal devices is blocked (or demands MFA plus compliance). For most enterprise environments where device management is deployed, this is appropriate.
One practical consideration: block access from non-compliant devices and you need a fallback. Users unable to reach Teams from their personal device will need either managed devices or an exception process. Mobile access is a particularly common pain point — enrolment in the device management service often takes longer on mobile devices, and blocking Teams access on personal mobiles affects after-hours availability.
Policies Using Named Locations
The identity service lets you define named locations for trusted IP ranges (VPN egress addresses, office networks) and geographic regions. Conditional Access policies can then be built that handle sign-ins from trusted locations differently from those originating in untrusted locations.
A common pattern is to require MFA for all sign-ins, while permitting MFA claim caching (so users are not constantly re-authenticating) only from named trusted locations. Every session requires MFA for users signing in from home or public Wi-Fi; on the corporate network, a cached MFA claim can be used for a longer duration.
Unmanaged Devices and Session Controls
Session-level controls for Teams web access are provided by the cloud defender service Apps (formerly MCAS), which integrates with Conditional Access. Rather than simply blocking or allowing access, web app access can be redirected through a reverse proxy that enforces extra controls: blocking file downloads, restricting certain actions based on device management status, and blocking copy-paste to external applications.
Particularly useful for guest or contractor scenarios where read access to Teams content is wanted but exfiltration must be prevented. Meetings can be joined and messages read, but the user cannot download files or take the content out of the Teams interface.
Policies Driven by Sign-In Risk
Risk-based Conditional Access is supplied by the identity service Identity Protection. Sign-in risk is calculated from signals such as anonymous IP addresses, atypical sign-in patterns, and impossible travel (signing in from two distant locations within an implausibly short time).
Might be required by a risk-based policy: MFA for medium-risk sign-ins, with access blocked for high-risk sign-ins. A layer of protection against credential theft is added without friction for normal sign-ins. Licensing requires the identity service P2 or the E5 plan for risk-based policies.
Rollout and Testing Strategy
Stage the rollout of new Conditional Access policies in phases:
- Report-only mode: First enable the policy in report-only mode. Nothing is enforced, but the logs record what would have happened. The impact can be understood by reviewing the logs in the identity service sign-in reports.
- Pilot group: Turn on enforcement for a small pilot group of technical users and IT staff who can troubleshoot issues.
- Broad rollout: Once the policy has been validated as behaving as expected and exception cases are handled, expand to all users.
Maintain a break-glass administrator account that is explicitly excluded from every Conditional Access policy. Use it only in emergencies, and monitor it closely for any sign-in activity.
Report-Only Output That Nobody Actually Reads
Conditional access can be deployed in report-only mode, where the policy is evaluated and the result written without enforcement. For introducing a Teams control, that mode is the right approach. It is useless, though, if the sign-in logs are not reviewed before the switch to enforce. A policy left in report-only for months is not a cautious rollout; it is an unenforced rule with a log nobody owns.
A policy requiring a compliant device for the Teams desktop and mobile clients was built by a city government with 5,000 accounts. Report-only ran for three weeks. According to the log, a quarter of successful Teams sign-ins would have been blocked, nearly all of them from personal phones used by inspectors who had never been asked to enrol a device. Field work would have stopped on a Monday had enforcement begun on the planned date. The remedy was a temporary exclusion for that role, an enrolment drive with a date on it, and only then the move to enforce. The log was the project; the policy toggle was the last step.
Read the report at the granularity of client app and user, not as a single percentage. A 5 percent would-block figure concentrated in one department is a different problem from a 5 percent figure spread across lost phones. Break-glass accounts should be excluded explicitly, and confirmed as not swept into an overly broad "emergency" group that has picked up ordinary users.
Named locations and sign-in risk belong in separate policies, so a failure in one control does not force the Teams policy to be disabled entirely. Testing becomes slower and rollback cruder when every condition is stacked into a single rule. When something breaks, you want one control switched off, not the whole access path to Teams.
For a week after enforcement, watch the helpdesk tags. A spike in "Teams won't sign in" from one office is frequently a location mis-classified as untrusted, or a device compliance policy that marks healthy machines as non-compliant because a single setting drifted. Both are faster to find in the conditional access insight workbook and the sign-in log failure reason than by guessing from the ticket text.
Note the policy id alongside the date it moved from report-only to on. The date gets asked for by auditors more often than the screenshot. A user-based grant will be failed by service accounts that sign in without a user present. Identify them in report-only before they fail a batch job. The resource tenant is where guest sign-ins are evaluated. Nothing about guests will be said by a policy scoped only to members. Where the grant requires an approved client app, test the web client separately. People fall back on it when the desktop install is blocked by another team. Never exclude an entire trusted location permanently because one executive travels. Put a time limit on the exclusion. Every directory cleanup should be followed by a re-check of exclusions. Disabled accounts are harmless. Enabled accounts excluded "just for the pilot" are not. Report-only results predating the last directory change are stale. Re-read them after large group edits. Unless it was a deliberate choice written into the description, a policy named for Teams should not also gate unrelated apps. Device compliance failures need the compliance policy name in the ticket guidance, otherwise the helpdesk will keep resetting Teams. Test using a user who has two devices, one compliant and one not. The result frequently is not the one the policy diagram suggests. In the portal, member policies and guest access policies are easy to confuse. Annotate the screenshot with which one you opened. For any trusted location, list the public addresses and the owner who confirms they still belong to the organisation. Rollback means disabling one policy, not every policy with Teams in the name. Cite the policy id in the change record. Monitor sign-in failures for 48 hours after enforcement, including the weekend if shift staff are in the pilot.
