Requiring MFA, not just offering it

The readiness guide asks whether MFA is required rather than merely available, and the wording is deliberate. Almost every service you use offers multi-factor authentication. Offering it protects the people who opted in. The account that gets compromised belongs to whoever did not.

The check is not "do we have MFA." It is "can anyone reach anything that matters with just a password," and answering it means opening consoles rather than recalling intentions.

Where to look, and what you are looking for

Four or five places cover most small teams. In each, you want a list of accounts and their enrolment status, not a policy statement.

Google Workspace

Admin console, then Security, then Authentication, then 2-step verification. Two distinct things live here: whether enforcement is on, and which organisational units it applies to. A policy enforced for the top-level unit but not an "Contractors" sub-unit is a real and common gap.

The evidence you want is in Reporting, then User Reports, then Security, which lists every user with a column for 2-step verification enrolment. Export it. That export is what an auditor means by evidence.

Microsoft 365 and Entra ID

Modern tenants have security defaults on, which enforces MFA for everyone. Older tenants often have them off because someone disabled them during a migration and never restored them, or because Conditional Access replaced them with rules that have exclusions nobody has read recently.

Check whether security defaults are enabled. If Conditional Access is in use instead, read the exclusion list on each policy. Break-glass accounts are legitimately excluded; a handful of ordinary users excluded during a project two years ago are not.

GitHub or GitLab

Organisation settings, then Authentication security. There is an option to require two-factor authentication for everyone in the organisation. Turning it on removes members who have not enrolled, which is why teams hesitate, and why it is worth announcing a date first.

Check outside collaborators too. They are not organisation members and are frequently missed by the organisation-wide setting depending on how they were added.

The ones that get forgotten

These are the accounts that control everything else, and they are often set up once by one person and never revisited:

• Your domain registrar. Whoever controls this controls your DNS, therefore your email, therefore password resets for nearly everything.
• Your DNS host, if separate.
• Your cloud provider root account, which typically has powers no ordinary user has.
• Your payment processor.
• Your hosting control panel.

If you check only one thing after reading this, check the registrar. It is the account most likely to be protected by a password from 2019 and least likely to be covered by whatever policy you rolled out to the team.

The shared-account problem

Every team accumulates a few logins that belong to nobody: a social media account, a shared support inbox, a vendor portal that charges per seat. These resist MFA because the second factor has to live somewhere, and "somewhere" is usually one person's phone.

Three workable answers, in order of preference:

1. Stop sharing the account. Many services now support multiple users on plans where they once did not. Worth checking before assuming.
2. Put the TOTP seed in a shared password manager entry. Most business password managers can store the seed and generate codes for anyone with access to that entry. This is a real reduction in security compared with individual accounts, and a real improvement over a shared password with no second factor at all.
3. Assign an owner and accept that access depends on them being reachable. Write down who it is, because the alternative is finding out during an incident.

Shared accounts also make offboarding substantially harder, because there is no account to disable. That is usually the stronger argument for removing them.

Rolling it out without a bad week

Enforcement removes access from anyone not enrolled. Done without warning on a Monday morning, this is an outage you caused yourself.

1. Announce a date, a fortnight out, with instructions.
2. Publish the enrolment report where the team can see it. Visible progress does more than reminders.
3. Chase individually in the last few days. There will be two or three.
4. Enforce on the date. Moving it teaches everyone that the next date is also negotiable.
5. Handle service accounts separately. Automation that logs in with a password cannot present a second factor and will break. These should be using API keys or service accounts rather than human logins, and enforcement day is when you find the ones that are not.

That last point is the one that catches teams out. A backup script or a reporting integration signing in as a person is both an MFA problem and a key scoping problem wearing a disguise.

Not all second factors are equal

In rough order of resistance to a determined attacker: hardware security keys, then authenticator apps, then push approvals, then SMS.

The meaningful difference is phishing. A security key verifies the site's origin before it signs anything, so a convincing lookalike domain gets nothing. A code from an authenticator app can be typed into a fake login page by a person who genuinely believes they are signing in. Push approvals sit in between and have their own failure mode, where a user tired of notifications approves one they did not initiate.

For most small teams, authenticator apps everywhere is a good and achievable standard. Hardware keys for the registrar, the cloud root account and the email administrator is a proportionate step up, and costs less than a week of the incident it prevents.

Recovery codes, and the account you cannot get back into

Enforcing MFA creates a new failure mode: someone loses the phone with the authenticator on it. Handled badly this locks a person out of their work, or worse, locks the whole company out of an account that controls everything else.

For staff accounts this is routine. An administrator resets their second factor and they re-enrol, which is why having more than one administrator matters.

The harder case is an account with no administrator above it: the domain registrar, the cloud root account, a vendor portal with a single owner. Losing the second factor there can mean a support process measured in weeks, with identity checks, while the account sits unreachable.

Three precautions, all cheap:

• Save the recovery codes at enrolment, in the shared password manager rather than a screenshot on somebody's desktop. Most services show them exactly once.
• Enrol a second factor where the service permits it: two hardware keys, or an authenticator plus a key, so losing one device is an inconvenience rather than an incident.
• Make sure more than one person can reach the critical accounts. A registrar accessible only through one individual's phone is a single point of failure for your entire domain, and it is usually discovered at the worst moment.

This is the same shape of problem as an untested restore: the control is in place and nobody has checked that the recovery path works.

What to keep

Keep the exports. An enrolment report from each system, dated, is the difference between saying you require MFA and being able to show it. It takes five minutes a quarter and it answers a questionnaire question that otherwise requires a paragraph of hedging.