Properly Securing Microsoft 365: Conditional Access, MFA Exceptions, and Break-Glass Accounts in Everyday Operations

Anyone who wants to secure Microsoft 365 properly cannot avoid Conditional Access (access-dependent policies in Entra ID, formerly Azure AD) and Multi-Factor Authentication (MFA, i.e., sign-in with at least two factors). In many organizations MFA and initial Conditional Access rules are enabled quickly — and then the work really begins: exceptions must be justified, emergency access organized cleanly, and operational processes designed so that security does not become a support avalanche.

In practice, „securing M365“ rarely fails because of the underlying technology, but because of everyday issues: service accounts for integrations, legacy protocols, field teams without reliable mobile connectivity, admins with overly broad privileges, or an incident in which the very protective measure blocks IT access. This article clarifies how Conditional Access, MFA exceptions and break-glass accounts interact — and how to operate the whole setup so it remains reliable after go-live.

Why Conditional Access is the lever — and why MFA alone is not enough

MFA significantly reduces the risk of stolen passwords, but MFA is not a complete access concept. Conditional Access (CA) decides contextually under which conditions an access is permitted: e.g. only from managed devices, only from specific countries, only with risk-based evaluation, or only with specific client apps. That is the decisive step toward Zero Trust (security model in which no access is trusted by default, but is continuously evaluated).

Typical reasons why MFA alone is not sufficient in Microsoft 365:

• Token instead of password: Modern authentication works with tokens (time-limited access tickets). A stolen token can bypass MFA if CA does not require additional conditions (e.g. device state or session control).
• Admin risk: Administrative accounts are particularly attractive. Without CA rules for admin access (e.g. only from admin workstations or only with phishing-resistant MFA) the largest attack surface remains open.
• „Allowed“ is too broad: If CA does not differentiate between apps, data classes and access types, security quickly becomes either too lax or too RESTrictive — both create problems.

The operational core is therefore: CA as the policy layer, MFA as a building block within it, plus clean exception management and robust emergency paths.

Architecture overview: What Conditional Access in Entra ID actually controls

For IT leadership and operations it is important not to view CA as „a single policy“ but as a decision chain. Entra ID evaluates signals at each sign-in and applies policies. Important signals are:

• Identity: users, groups, roles (e.g. privileged roles such as Global Administrator).
• Target resource: cloud app (Exchange Online, SharePoint/OneDrive, Teams, but also third parties via Enterprise App).
• Client type: browser, modern clients, mobile apps, as well as „Legacy Authentication“ (older protocols without modern tokens, e.g. older IMAP/POP/SMTP auth variants).
• Device state: „Compliant“ or „hybrid joined“ (managed device, typically via Intune or domain-joined with device status).
• Network/location: Named Locations (defined IP ranges), countries/regions, risk indicators.
• Session conditions: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (continuous re-evaluation in case of risk events).

From an operational perspective, the quality of your CA configuration strongly depends on whether its signals are reliable. A Named Location is only as good as your IP address hygiene. “Compliant” is only as good as your device management and the definition of compliance. And a risk assessment is useful only if you actually act on the events it produces.

Securing Microsoft 365 correctly with Conditional Access: a practical policy set

Rather than a single “big” rule, a set of a few clearly delimited policies works better in daily operations. That reduces side effects and makes incident troubleshooting easier. A proven basic pattern consists of:

1) Baseline for all users: enforce MFA, block Legacy Authentication

For regular user accounts the baseline is: MFA required, and Legacy Authentication blocked. Legacy here is not “old-fashioned” but technically problematic: these protocols often do not support a modern MFA challenge and are therefore a classic entry point for password spraying.

Important: Do not block Legacy “at some point” without planning — schedule a transition phase with measurement. Use Sign-in logs to check which clients still use Legacy. In enterprises these are often multifunction printers, scan-to-mail, or older mail clients in specialized environments.

2) Admin policy: significantly stricter than the baseline

Privileged roles should have their own policy: access only from defined admin devices (e.g., “compliant” and, where appropriate, a separate admin workstation strategy), MFA with high assurance (phishing-resistant, e.g., FIDO2/Passkey or certificate-based), and, if feasible, restrictions for high-risk countries/locations. Even if not every organization immediately implements a full privileged access architecture (PAM, i.e. privileged access management), this distinction pays off immediately: a compromised admin account has a different damage scope than a compromised user account.

3) Policy for external collaboration and guests

Guest access (B2B Collaboration) often creates unexpected data paths: guests download files from SharePoint, work in Teams, or access project portals. Define explicitly whether guests must use MFA, which apps are excluded, and how long sessions remain valid. For project work a shorter session lifetime is often sensible to reduce the risk of “forgotten logins.”

4) Policy for sensitive data paths: secure device or session

Daily operations have different protection needs: a sales representative may be allowed to read e‑mail from any device, but not to download large data sets from SharePoint without a managed device. You do not model such differences with blanket “allow/deny” rules, but with CA combinations: “access allowed if device is compliant” or “access only via browser with a restricted session.” That is less rigid than a full block — and still effective.

MFA exceptions: where they are realistic — and how to control them

MFA exceptions are not a sign of weakness as long as they are deliberately designed and operationally controlled. Without controlled exceptions shadow solutions arise: users circumvent processes, admins panic and disable rules, and eventually the policy set becomes incomprehensible.

The important distinction: an MFA exception rarely means “MFA off”; it often means “MFA differently” or “access only under different conditions.” Typical exception categories:

Exception case 1: non-interactive access and interfaces

Many process-near software solutions integrate M365 services: email sending, calendar access, SharePoint file storage, Teams notifications or Graph API accesses. Such integrations should not run via user accounts with MFA disabled. A better approach is a technical access via app registrations (application in Entra ID) with explicit permissions and a secret/certificate lifecycle. This is not an „MFA exception“, but a different authentication method that is more auditable.

Operational consequences: Secrets must be rotated, certificates expire, and permissions must be recertified. When you plan integrations, define ownership (who renews certificates/secrets) and monitoring (e.g., alerts before expiry). Otherwise „secure“ app auth becomes an unplanned outage.

Exception case 2: Devices without modern login (e.g. scanners, printers, room systems)

This is where the classic discussions about SMTP relay, scan-to-mail or room mailboxes arise. The wrong solution is almost always „a user account without MFA.“ Better are technical paths that do not depend on interactive sign-in: a central mail relay with IP RESTriction, certificate- or connector-based approaches, or separate system mailboxes with narrow permissions. Crucial is: the device itself cannot handle MFA, so the design must secure the transport and network path.

Exception case 3: emergency operation and limited reachability

Field service, production or shift work encounter situations without mobile reception or without personal mobile devices. It is therefore worth considering alternative MFA methods early: hardware tokens, FIDO2 security keys, or Windows Hello for Business (device-bound sign-in). „Temporarily turning MFA off“ is operationally tempting, but scales poorly and is difficult to audit.

Exception case 4: automated jobs with user context

Some legacy systems start jobs „as user“, for example for SharePoint uploads or reports. From today’s perspective this is risky because it mixes roles and access rights. If replacement is not immediately possible, work with intermediate stages: limited service accounts, clear Named Locations, strong password/secret policies and consistent logging. And: plan the migration to app identities as its own work package, not as „sometime later.“

How to document, approve and retire exceptions

Exceptions are acceptable in operations only if they have a lifecycle. A lightweight approach that avoids bureaucracy but remains auditable has proven practical:

1. Justification in one sentence: Which business or operational function depends on it (e.g., „Scan-to-Mail at location X“)?
2. Technical classification: Which app/protocols, which accounts, which data paths?
3. Compensating controls: What limits the risk (IP RESTriction, least necessary privileges, monitoring)?
4. Expiry date: Every exception receives a review date. Without review it is removed or reapproved.
5. Owner: Who is responsible if it breaks or when the exception expires?

That does not make exceptions „good“, but it makes them controllable. And that is precisely the everyday difference between a robust M365 security baseline and policy chaos.

Break-Glass-Accounts: emergency access without a security hole

Break-Glass-Accounts are emergency accounts for tenant access when regular admin paths fail – for example due to a misconfiguration in Conditional Access, an outage of an MFA provider, or an identity incident. The purpose is clear, but implementation has typical pitfalls: a Break-Glass account that is never tested won’t help in an emergency. A Break-Glass account that is too conveniently accessible becomes an attractive attack target.

What Break-Glass is not

• Not a daily admin account: It must not be used in normal operations.
• Not a catch-all for exceptions: It does not replace a clean CA design.
• Not a „we have one, that’s fine“ mindset: Without process, testing and alerting it is only a theoretical plan.

Basic principles for Break-Glass in operation

A practical setup orients around three objectives: reachable in an emergency, hard to attack in normal operation, and auditable.

• At least two accounts: Redundancy against lockout, operator error or compromised credentials.
• Strongly secured: Long, random passwords; no email forwarding; no use for apps/integrations.
• Explicitly excluded from CA – but narrowly: A typical pattern is an exception from specific CA policies so you are not locked out by your own rules in an emergency. At the same time, other security controls should remain in effect: alerts on use, RESTrictive role assignment, and separate storage of credentials.
• Logging and alerting: Every sign-in must trigger an immediate signal (SIEM/SOC or at least email/Teams alert to an incident mailbox). Break-Glass usage is by definition a security event.

A central point: decide deliberately whether Break-Glass is operated with or without MFA. Many organizations run it without MFA to remain operational in case of an MFA outage. If so, compensating controls must be especially rigorous (secure storage, controlled access to the password, alerting, regular rotation). Alternatively, Break-Glass can be protected with hardware-based MFA (e.g., FIDO2) that is independent of cellular networks. The important thing is not the „right“ ideology but an emergency path that actually works in your context.

Rollout reality: How to avoid lockouts and support spikes

Many CA/MFA rollouts fail not for technical reasons but organizational ones: too fast, too broad, without telemetry and without a clear support process. A stable rollout works in waves with measurement points.

Step 1: Create visibility (before you block)

Use Sign-in Logs and analyses to find out: which apps are used? Which clients are „legacy“? Which locations/IP ranges are real? Which users have particularly many sign-in problems? Without this data, every policy is a blind flight.

Step 2: Pilot groups with real edge cases

Pilots should not be just „IT and a few volunteers.“ Intentionally include boundary cases: field staff, production sites, project workers with guest access, and at least one department using common third-party tools. The goal is not harmony but early discovery of real stumbling blocks.

Step 3: Define helpdesk playbooks

When MFA is enforced, tickets increase: device changes, lost phones, new employees, account locked after too many attempts. Define what first-level support may resolve (e.g. MFA reset after identity verification) and when to escalate. Without playbooks everything escalates — and the admins become the bottleneck.

Step 4: Technical follow-up as its own backlog

CA makes hidden technical debt visible: legacy email clients, undocumented scanners, scripts with passwords in the Task Scheduler, or integrations that still use Basic Auth. Plan these follow-up tasks as visible work items. Otherwise they remain as ‚permanent exceptions‘.

Typical operational failure patterns — and how to triage them faster

In daily operations, rapid hypotheses matter. Some patterns recur:

“Suddenly Outlook stops working”

Common causes: legacy client, old profile, or a CA block because the device is not compliant. Check: client type in the Sign-in Log, applied CA policy, and whether the device is listed as compliant. The operational fix is rarely ‚turn off the policy‘; more often it is ‚modernize the client‘ or ‚clean up device management‘.

“Service XY can no longer send emails”

Often a change in SMTP authentication, an altered relay policy, or a new CA rule is behind it that unintentionally also affects technical/service accounts. Here a clear architectural decision helps: sending via relay/connector instead of a user login, with IP RESTriction and logging (traceability in the incident).

“Admin can no longer access the tenant”

This is the moment Break-Glass is intended for. If the Break-Glass access also fails, there is usually no tested emergency path or the exception was built incorrectly. Therefore: practice using it regularly (with documentation of who tests when and what the alert looks like).

“Too many exceptions — nobody can keep track”

That is a governance problem. Consolidate policies, define a review ritual (e.g. 30 minutes monthly), and remove exceptions that no longer have an owner or purpose. Technically this is not glamorous, but it is the difference between controllable security and historically accumulated special privileges.

Monitoring and traceability: What you really need

CA and MFA generate many events. If you collect everything, you drown; if you analyze nothing, you discover problems too late. Practically, three levels are useful:

• Alerting on critical events: Break-Glass login, admin login from unusual countries, block events on critical apps.
• Regular reviews: top block reasons, top users with MFA issues, legacy-auth attempts, new apps/Enterprise Apps.
• Audit trail for exceptions: who approved which exception, with what expiry date, and when it was reviewed?

If you already have centralized logging and incident processes (SIEM, ticketing, change management), anchor CA changes there. Conditional Access is not a ’small setting‘ but a production-critical access layer.

Effort and responsibilities: Who must deliver what?

CA/MFA projects are undeRESTimated because they look like pure configuration. In reality they are interface projects between identity, endpoints, network and business processes. A clean responsibility model reduces friction:

• Identity team / Entra Admins: policy design, role model, Break-Glass, app registrations.
• Client management (e.g. Intune): compliance definition, device state, rollout of Authenticator/passkeys, device lifecycle.
• Network: IP ranges for Named Locations, proxy/TLS inspection exceptions, site relocations.
• Service owners of business applications: integration paths (Graph/SMTP/SharePoint), migration from legacy auth, secret rotation.
• Helpdesk: standard processes for MFA reset, device replacement, onboarding/offboarding.

The most important management decision is often not „MFA yes/no“, but: Do we have the time and resources for the follow-up work (phasing out legacy systems, modernizing integrations, stabilizing device management)? Without this work the security gain will fall short of expectations—or operations will become unnecessarily difficult.

Conclusion: Security wins when emergency procedures and exceptions are part of the system

Securing Microsoft 365 properly means operating Conditional Access as a central control layer — not as a one-off configuration. MFA is mandatory, but true operational quality arises from clean exceptions (with expiry date, owner and compensating controls) and from break-glass accounts that are tested, monitored and organizationally embedded. Those who consider these three elements together reduce account risks, gain auditability without overhead, and prevent security rules from turning into an adversary during an incident.

Discuss a project or modernization initiative with Net-Base.