Multi-factor authentication
A second proof of identity beyond a password, applied across email, files, and any business application that supports it - not only the one system that happened to prompt for it first.
Identity & access / A recurring rhythm, not a bullet point
Multi-factor authentication, conditional access, and password hygiene usually get a single bullet inside a bigger service description. They deserve the same treatment a device already gets: a named owner, a recurring cadence, and a plain description of what good looks like.
Read this page in FrenchWhy this needs its own rhythm
A new employee's account gets configured correctly on day one, multi-factor authentication included. Eighteen months later, nobody has looked at it since - no review of what it can reach, no confirmation the recovery details are still correct, no check that a contractor's temporary access ever actually expired. Identity is not a setup task finished at onboarding. It is a standing responsibility with its own cadence, whether or not a provider names it that way.
Four pieces, one rhythm
A second proof of identity beyond a password, applied across email, files, and any business application that supports it - not only the one system that happened to prompt for it first.
Conditions that call for extra scrutiny on an unfamiliar location, a new device, or a sign-in pattern that does not match how someone normally works, instead of treating every login identically.
One verified identity carried across the applications that support it, so people are not juggling a different password for every system they touch.
Passphrases instead of short complex strings, a password manager instead of reused logins, and a clear break from writing credentials on paper or in a shared spreadsheet.
Across the identity lifecycle
| Moment | Typical action | Decision owner |
|---|---|---|
| New account | Create the account, assign licensing, enrol multi-factor authentication before first use | Managed service, per the agreed standard |
| Routine access review | Confirm who can reach what, and whether it still matches the role | Managed service proposes; your team confirms sensitive changes |
| Suspicious sign-in | Investigate the alert, challenge or lock the session, contact the employee directly | Managed service, escalated immediately when warranted |
| Departure or role change | Remove or adjust access on the agreed timeline | Your team confirms the trigger date; managed service executes |
This is not a claim of a specific compliance framework, a maturity score, or a breach-prevention guarantee. It describes what a workable identity rhythm actually contains - exact tools and coverage are confirmed in writing for your environment. See how a departure connects to the wider onboarding and offboarding sequence
Who this fits
A good fitTeams where every employee has a named account across email, business applications, and any remote-access tool, and where multi-factor authentication is realistic to enforce.
Probably not the fitEnvironments still relying entirely on shared logins with no individual accounts, or a single specialized system whose own vendor already manages its own identity model end to end.
Before you compare providers
Every provider will say they use multi-factor authentication. The more useful question is what happens after enrollment: who reviews access every few months, who gets contacted when a sign-in looks wrong, and how access actually gets shut off on the day a departure happens - not the day someone remembers to do it. See how identity review fits the recurring maintenance rhythm
See the security layers beyond the login itselfNext step
The service map turns your context into a short, copyable list: people, devices, Microsoft 365, vendors, and decisions to clarify.
Build the service map