Multi-factor authentication, single sign-on, and Conditional Access are usually sold as settings to turn on. The harder question is who is allowed to be the exception—the contractor without a company device, the vendor account that cannot support MFA, the one break-glass login kept outside every rule—and who signs off on that gap.
The decision to enable
Decide which identity controls apply to which population, who is allowed an exception, and who owns the emergency-access account that sits outside all of them.
01
Start from who signs in, not which feature to enable
Multi-factor authentication, single sign-on, and Conditional Access are controls applied to people and accounts, not a single company-wide switch. Group who signs in by risk and consequence—administrators, staff handling client or financial data, contractors, service accounts, and shared logins—before deciding which control applies to which group and why.
Which accounts can reach financial systems, client data, or administrative settings
Which sign-ins happen from an unmanaged device, a personal phone, or outside Canada
Which accounts are shared, generic, or used by more than one person
02
Treat every exception as a decision, not a workaround
A contractor who cannot install an authenticator app, a line-of-business system that cannot support modern sign-in, an executive who finds MFA prompts irritating while travelling—each is a real constraint, and each is also a decision that needs an owner. An exception granted quietly by whoever configured the tenant is not the same as an exception leadership has actually approved.
03
Name who owns the break-glass account before you need it
A break-glass account—an emergency sign-in kept outside Conditional Access, MFA enforcement, and normal approval flows—exists so administrators are not locked out of their own systems during an outage or a misconfiguration. It is also, by design, the account every other control does not apply to. Someone specific should know it exists, hold its credentials under controls appropriate to that risk, and check periodically that it has not been used quietly.
Who holds the credentials, and how they are stored
What would trigger its use, and who is told afterward
How often its existence and access are actually reviewed
04
Decide who approves an exception, and for how long
An exception without an expiry date usually becomes permanent by default. State who can approve a departure from the standard policy, what compensating step applies while the exception exists—a more restrictive network location, a shorter password rotation, closer log review—and when it comes back for another look.
Decision frame
What leadership should be able to verify.
These criteria do not produce a score. They expose the questions that need resolution before a responsible decision.
CriterionUseful signalLeadership question
PopulationEvery account is grouped by risk and consequence, not treated as one policy.Which accounts can reach financial systems, client data, or admin settings?
ExceptionDepartures from the standard policy have a named approver and a reason.Who actually approved this account being exempt, and why?
Break-glassThe emergency account is named, controlled, and reviewed on a schedule.Who holds the credentials to the account no policy applies to?
ExpiryEvery exception carries a review date instead of running indefinitely.When does this exception come back for another look?
Practical scenarios
The same discipline applied to different decisions.
A key vendor’s system cannot support modern sign-in
Situation: A line-of-business application used daily by the finance team only supports a basic username-and-password login, with no path to single sign-on or multi-factor authentication.
Useful response: Treat the gap as a named, time-bound exception with a compensating control—tighter network restriction, a stronger unique password, closer log review—rather than a silent hole in an otherwise consistent policy, and revisit it whenever the vendor’s own roadmap changes.
Boundary: This guide does not evaluate a specific vendor’s authentication roadmap or promise a workaround exists for every legacy system.
An executive asks for a standing exemption from sign-in prompts while travelling
Situation: A senior leader finds repeated authentication prompts disruptive during frequent international travel and asks IT to turn Conditional Access off for their account.
Useful response: Separate the real friction—prompt frequency, trusted-location rules, session length—from the request to remove the control entirely, and bring the actual trade-off back to leadership as a named decision rather than quietly weakening the account with the most access.
Boundary: This guide does not configure a specific Conditional Access policy or identity platform on your behalf.