Conditional Access is one of the most powerful security controls available in Microsoft 365, and it's the right place to start a conversation about Teams access security. The basic concept: instead of granting access to Teams unconditionally to any authenticated user, you add conditions. If the device isn't compliant, require additional verification. If the user is signing in from an unusual location, require MFA. If the app is being accessed from a personal device, restrict what they can do.
Conditional Access is configured in Microsoft Entra ID (formerly Azure AD), not in the Teams Admin Center. But it applies directly to Teams — and to all Microsoft 365 apps — through the cloud app targeting mechanism.
The Structure of a Conditional Access Policy
A Conditional Access policy has three parts: assignments (who does this apply to, and under what conditions), target resources (which apps does this apply to), and access controls (what happens when the conditions are met).
Assignments include: users/groups, cloud apps or actions, conditions (device platform, location, sign-in risk, client apps). Target resources can be specific cloud apps (like Office 365) or all cloud apps. Access controls are: grant access (with or without MFA, device compliance, or other requirements) or block access.
Core Policy: Require MFA for Teams
If you don't have any Conditional Access policies today, this is where to start. A policy that requires MFA for all users accessing Microsoft 365 apps (including Teams) is the single highest-ROI security control available.
Policy configuration:
- Users: All users (or start with a pilot group)
- Target: Office 365 (covers Teams, SharePoint, Exchange)
- Conditions: None (apply universally)
- Access control: Require multi-factor authentication
- Client apps: Include browser, mobile, and desktop. A policy that covers only the browser leaves the desktop client, which is how most people actually open Microsoft Teams.
- Grant versus block: Prefer a grant of access when controls are satisfied. A block aimed at "legacy authentication" is a different policy and should not be merged into the Teams grant rule until both have been tested.
Before enabling this for all users, ensure that all users have registered an MFA method. If you enable MFA enforcement before users have registered, you'll lock them out. Microsoft's MFA registration campaign (in Entra ID > Identity > Overview > Users > MFA registration) can help drive registration before enforcement.
Device Compliance Policies
A device compliance policy requires that the device accessing Teams is managed by Microsoft Intune and meets a defined compliance standard (encryption enabled, OS version current, antivirus running, etc.).
Adding a device compliance requirement to your Teams Conditional Access policy means that access from unmanaged personal devices is blocked (or requires MFA plus compliance). This is appropriate for most enterprise environments where device management is deployed.
Practical consideration: if you block access from non-compliant devices, ensure you have a fallback. Users who can't access Teams from their personal device will need either managed devices or an exception process. Mobile access is a particularly common pain point — mobile devices often take longer to enrol in Intune, and blocking Teams access on personal mobile devices affects after-hours accessibility.
Named Location Policies
Named locations in Entra ID allow you to define trusted IP ranges (office networks, VPN egress addresses) and geographic locations. You can then build Conditional Access policies that treat sign-ins from trusted locations differently from sign-ins from untrusted locations.
A common pattern: require MFA for all sign-ins, but allow MFA claim caching (so users don't re-authenticate constantly) only from named trusted locations. Users signing in from home or public Wi-Fi need to complete MFA every session; users on the corporate network can use a cached MFA claim for a longer duration.
Session Controls for Unmanaged Devices
Microsoft Defender for Cloud Apps (formerly MCAS) integrates with Conditional Access to provide session-level controls for Teams web access. Instead of just blocking or allowing access, you can redirect web app access through a reverse proxy that enforces additional controls: blocking file downloads, blocking copy-paste to external applications, and restricting certain actions based on device management status.
This is particularly useful for guest or contractor scenarios where you want to allow read access to Teams content but prevent exfiltration. The user can participate in meetings and read messages, but they can't download files or take the content out of the Teams interface.
Sign-In Risk Policies
Entra ID Identity Protection provides risk-based Conditional Access. Sign-in risk is calculated based on signals like impossible travel (signing in from two distant locations within an implausibly short time), anonymous IP addresses, and atypical sign-in patterns.
A risk-based policy might require MFA for medium-risk sign-ins and block access for high-risk sign-ins. This adds a layer of protection against credential theft without adding friction for normal sign-ins. Risk-based policies require Entra ID P2 or Microsoft 365 E5 licensing.
Testing and Rollout Strategy
New Conditional Access policies should be rolled out in stages:
- Report-only mode: Enable the policy in report-only mode first. This logs what would have happened without enforcing anything. Review the logs in the Entra ID sign-in reports to understand the impact.
- Pilot group: Enable enforcement for a small pilot group of IT staff and technical users who can troubleshoot issues.
- Broad rollout: Expand to all users after validating that the policy behaves as expected and exception cases are handled.
Always have a break-glass administrator account that is explicitly excluded from all Conditional Access policies. This account should be used only in emergencies and should be monitored closely for any sign-in activity.
Report-only Mode That Nobody Reads
Conditional access can be deployed in report-only mode, which evaluates the policy and writes the result without enforcing it. That mode is the right way to introduce a Microsoft Teams control. It is useless 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 city government with 5,000 accounts built a policy requiring a compliant device for the Teams desktop and mobile clients. Report-only ran for three weeks. The log showed that a quarter of successful Teams sign-ins would have been blocked, almost all of them from personal phones used by inspectors who had never been asked to enrol a device. Enforcing on the planned date would have stopped field work on a Monday. The fix was a temporary exclusion for that role, an enrolment drive with a date on it, and only then a move to enforce. The log was the project. The policy toggle was the last step.
Read the report at the granularity of user and client app, not as a single percentage. A 5 percent would-block figure that is concentrated in one department is a different problem from a 5 percent figure spread across lost phones. Exclude break-glass accounts explicitly and confirm they are not excluded by an overly broad "emergency" group that has picked up ordinary users.
Named locations and sign-in risk belong in their own policies so a failure in one control does not force you to disable the Teams policy entirely. Stacking every condition into a single rule makes testing slower and rollback cruder. When something breaks, you want to turn off one control, not the whole access path to Microsoft Teams.
After enforcement, watch the helpdesk tags for a week. A spike in "Teams won't sign in" from one office is often a location mis-classified as untrusted, or a device compliance policy that marks healthy machines as non-compliant because a single setting drifted. The conditional access insight workbook and the sign-in log failure reason are faster than guessing from the ticket text.
Record the policy id and the date it moved from report-only to on. Auditors ask for the date more often than for the screenshot. Service accounts that sign in without a user present will fail a user-based grant. Find them in report-only before they fail a batch job. Guest sign-ins are evaluated in the resource tenant. A policy scoped only to members will not say anything about guests. If the grant requires an approved client app, test the web client separately. People use it when the desktop install is blocked by another team. Do not exclude an entire trusted location permanently because one executive travels. Time-box the exclusion. Re-check exclusions after every directory cleanup. Disabled accounts are harmless. Enabled accounts that were excluded "just for the pilot" are not. Report-only results older than the last directory change are stale. Re-read them after large group edits. A policy named for Teams should not also gate unrelated apps unless that was a deliberate choice written in the description. Device compliance failures need the compliance policy name in the ticket guidance, or the helpdesk will keep resetting Teams. Test with a user who has two devices, one compliant and one not. The result is often not the one the policy diagram suggests. Guest access policies and member policies are easy to confuse in the portal. Label the screenshot with which one you opened. If a location is trusted, list the public addresses and the owner who confirms they still belong to the organisation. Rollback is disabling one policy, not every policy with Teams in the name. Name the policy id in the change record. Watch sign-in failures for 48 hours after enforcement, including the weekend if the pilot includes shift staff.
