Securing Microsoft 365: accounts, MFA and access.

Before changing a setting, list everything that connects to your Microsoft 365 environment: users, administrators, providers, guests, applications and devices. Even a well-chosen security policy can block an essential application or an employee travelling for work if the inventory has overlooked them.

Then count your Global Administrators. Microsoft recommends assigning this role to fewer than five people and keeping privileged role assignments below ten. This role can read and modify almost every setting in the organisation. Check who holds it today, and why.

Finally, identify two cases that will cause problems later. The first is user accounts used by a script or application. The second is devices or software that connect with only a username and password, such as a copier that sends emails. Record recent joiners and leavers, without removing access whose purpose has not yet been established. For departures, Teams, SharePoint, OneDrive: what goes where? explains what happens to the files belonging to a deleted account.

• Name the person responsible for each administrator account
• Check access for providers, guests and former employees
• List the applications, scripts and devices that connect
• Separate administration accounts from everyday work accounts

Multifactor authentication, or MFA, adds a second proof of identity to the password, such as approval in an app on a phone. Microsoft now requires it on its administration portals, regardless of your tenant settings. According to Microsoft's page on mandatory MFA, enforcement takes place in two phases, rolled out progressively across tenants.

All accounts that sign in to these services are affected, including emergency access accounts. Microsoft recommends securing them with a FIDO2 passkey or certificate-based authentication. User accounts used by scripts or automations must also complete MFA. Microsoft recommends replacing them with workload identities, such as managed identities, which are not subject to this requirement.

For an SME, the question is therefore no longer whether administrators will use MFA, but which method they will use. Also check with your IT lead that no script still depends on a user account protected by only a password.

Microsoft Authenticator suits most users. For administrators, aim for a phishing-resistant method. With security defaults, users register Authenticator in notification mode and enter the number shown on screen, reducing the risk of approving a request out of fatigue. A third-party app that generates OATH TOTP codes is also accepted.

Microsoft recommends moving away from SMS and voice calls for MFA in favour of modern methods such as Authenticator. However, codes and notifications remain exposed. According to Microsoft's overview of authentication methods, these options are susceptible to remote phishing: an attacker obtains a password or one-time code without touching the user's device.

Phishing-resistant methods require direct interaction between the authentication method and the sign-in interface. In its authentication methods overview, Microsoft lists Windows Hello for Business, FIDO2 passkeys including those stored in Microsoft Authenticator, FIDO2 security keys and certificate-based authentication. With Entra ID P1, a Conditional Access policy can require these methods for administrator roles: Microsoft places this rule in the first phase of its rollout plan.

The most frequently quoted figure comes from Microsoft. According to research cited on its mandatory MFA page, MFA can block more than 99.2% of account compromise attacks. This is the vendor's figure, with no detailed methodology on that page. It is sufficient to justify MFA for everyone. The choice of method matters most for accounts with the greatest power.

• Users: Microsoft Authenticator with number matching, or a passkey in Authenticator
• Administrators: a FIDO2 passkey, Windows Hello for Business or a certificate
• Emergency accounts: a FIDO2 key or certificate, different from other administrators' methods
• SMS and voice calls: replace them; Microsoft recommends no longer using them for MFA

Without an Entra ID P1 licence, enable security defaults. With P1, Conditional Access provides the same protections with exceptions and group-specific policies. The two cannot be combined: Microsoft states in its Conditional Access deployment plan that creating Conditional Access policies prevents security defaults from being enabled.

Security defaults are free and cannot be customised: they are either enabled or disabled. They require all users to register for MFA, and require MFA at every sign-in for sixteen administrator roles. Other users complete MFA when Microsoft considers it necessary, and everyone must complete it to manage Azure.

They also block legacy authentication and the device code flow, a sign-in method designed for devices without a keyboard that has been misused in phishing attacks. Since 29 July 2024, users no longer have a 14-day grace period to register: prepare them before enabling it.

Conditional Access applies policies based on sign-in context: user, application, device or IP location, down to country level. It requires at least Entra ID P1, included in Microsoft 365 Business Premium. Policies based on sign-in risk or user risk require Entra ID P2 with Microsoft Entra ID Protection. Check the licences actually assigned to the people concerned, not just the subscription name.

Microsoft also creates Microsoft-managed Conditional Access policies in eligible tenants, for example to block legacy authentication or require phishing-resistant authentication for administrators. They arrive in report-only mode and are generally enabled at least 30 days later, with two weeks' notice by email and in the Message centre. Microsoft identifies cases with a shorter notice period in those messages. Exclude your emergency accounts from them, just as you would from any other policy.

Legacy authentication refers to sign-ins using protocols that do not support MFA, such as basic authentication, with only a username and password. Exchange Online has already removed it for POP and IMAP, but it remains possible for sending email through SMTP AUTH. An attacker who knows a password can use these protocols to bypass MFA. Microsoft recommends blocking them. According to its analysis, more than 99% of password spray attacks and more than 97% of credential stuffing attacks use these protocols.

Before blocking them, check who uses them. In the Microsoft Entra admin centre, sign-in logs can be filtered by client application to show legacy protocols. Run the same search in the non-interactive sign-ins tab.

Consider devices that send email, such as a multifunction copier or a business application using a mailbox's username and password. Microsoft states that SMTP sending with basic authentication is incompatible with security defaults. The alternatives described are modern OAuth authentication, if the device supports it, or an SMTP relay connector authenticated by a TLS certificate or public IP address. Microsoft has already disabled SMTP AUTH in tenants where it was unused, and has announced the removal of basic authentication for SMTP AUTH in Exchange Online. The timetable has already changed: consult the latest official announcement before planning, and check what your devices support.

Announce changes before applying them: what will change at sign-in, the date, the method to register and the person to contact if access is blocked. Users register their methods on the Security info page in the My Profile portal (myprofile.microsoft.com).

Then test with a pilot group covering different situations: office work, travel, business applications and administration. For Conditional Access, each new policy can first run in report-only mode: it is evaluated at every sign-in without being enforced, and the result appears in the sign-in logs. Microsoft advises leaving each policy in this mode for at least one week before enforcing it, while reviewing the logs. It proposes a three-phase rollout over approximately four weeks. First, block legacy authentication and protect administrators; then require MFA for all users and guests; finally, introduce risk-based policies with P2.

Do not leave a gap between the old and new protection baselines. Microsoft says to enable Conditional Access policies immediately after disabling security defaults. Prepare everything before switching: emergency accounts, registered methods and drafted policies. Immediately enable at least the policies that reproduce the default protections. More granular policies should first spend their week in report-only mode.

Conversely, if you enable security defaults, Microsoft recommends revoking existing sessions so that each user signs in again and registers. This planning forms part of the Microsoft 365 management we carry out with your teams.

Write the recovery procedure before you need it: who can initiate it, how the requester's identity is verified and what record is retained. A message from an unfamiliar address or an urgent phone call does not prove identity. That is exactly what an attacker will try to gain access to an account.

The Temporary Access Pass, or TAP, is Microsoft's tool for this purpose. It is a time-limited code that allows a user to sign in and register a new method, such as Authenticator on a new phone or a FIDO2 key. The method must be enabled in the authentication methods policy for the users concerned. An Authentication Administrator can create a TAP for a user. For an administrator, the Privileged Authentication Administrator role is required. Nobody can create one for themselves.

By default, a TAP is valid for one hour, and the policy can allow a duration from 10 minutes to 30 days. Enable single use if each code should work only once. Only internal guests can receive one: it cannot be used for external guests.

• Verify identity according to a written procedure, for example confirmation by the person's line manager
• Issue a short-lived TAP, preferably for a single use
• Have the new method registered, then remove the old one from the account
• Record the intervention: requester, verification performed, administrator and date

An emergency access account is used when no administrator can sign in: a misconfigured policy, unavailable MFA methods or the departure of the last Global Administrator. Microsoft recommends at least two accounts, reserved for these situations and protected by a phishing-resistant method.

These accounts are not associated with any particular person. Their credentials are kept in separate, secure locations accessible to several authorised people. Do not keep the procedure only in a space that depends on the account you are trying to recover, such as a SharePoint folder or a mailbox in the same tenant. Microsoft advises placing them in a dedicated group so that they can easily be excluded from policies. Mandatory MFA also applies to them: an emergency account protected by only a password can no longer open administration portals.

• At least two cloud-only .onmicrosoft.com accounts, without federation or synchronisation
• Global Administrator role assigned permanently, rather than eligible in Privileged Identity Management
• A FIDO2 passkey or certificate, different from other administrators' methods
• Excluded from all Conditional Access policies that block or restrict sign-in, including Microsoft-managed policies
• An alert whenever one of these accounts signs in
• A sign-in test at least every 90 days

The following example is fictional and illustrates the steps above. A 25-person accounting and fiduciary firm uses Microsoft 365 Business Premium. Its inventory reveals three Global Administrators: the director who created the subscription, the IT manager and an account belonging to a former provider that was never disabled. The copier sends scanned documents through SMTP using a mailbox password.

The business removes the role from the provider's account, then disables that account. It creates two emergency accounts with FIDO2 keys stored in two different locations, and routes the copier through an SMTP relay connector. It then enables three policies for a pilot group of five people, followed by everyone else: block legacy authentication, require a phishing-resistant method for administrators and require MFA for all users.

Three weeks later, a salesperson loses their phone while travelling. Their manager confirms their identity during a video call, and the IT manager issues a single-use TAP valid for one hour. The salesperson registers Authenticator on their new phone, the old device is removed from their account and the intervention is recorded.

Without this preparation, the provider's account would have remained an entry point into the entire tenant. The copier would have stopped sending emails on the day the block was introduced, and the lost phone would have been handled through a reset agreed over the phone, without verification.

Gather the access inventory, licences and existing procedures, then agree the settings, responsibilities and timetable. If the state of your accounts is unclear, preparing for an IT audit or requesting an IT audit provides a starting point.

• How many Global Administrators do we have, and who uses them?
• Do emergency accounts exist, and when were they tested?
• Which applications or devices still use legacy authentication?
• Do the licences cover Conditional Access, and for which users?
• Who can issue a TAP, and under which procedure?
• How will users be informed and supported on the day of the change?