An authenticator app on everyone's phone looks reassuring. It doesn't answer the whole question of how your business accounts are protected. The method might be registered but not required for a particular service, or a separate sign-in route might have been overlooked.
You don't need to become an identity specialist to ask better questions. Start with one cloud service and ask your IT provider to show how a real user gets from its sign-in page to business information. Keep the settings and the observed result together.
Start with the requirement
The current NCSC requirements require MFA where available and always for authentication to cloud services. IASME's April 2026 guidance says failing to implement available cloud MFA causes an automatic assessment failure, including when it requires a paid option.
If a supplier says its service cannot support MFA, bring the actual arrangement to your Certification Body. A note saying that MFA is inconvenient or costs extra doesn't settle the assessment question. The checks below are a practical discussion guide, not a substitute for the official requirements.
Choose one service and name the routes into it
Pick a service you already use, such as bookkeeping or file storage. Write down its name, its owner in your business and where users sign in. Ask colleagues how they normally open it. Their answer may be different from the link in your IT documentation.
Some people might use a button labelled “Sign in with Microsoft”, while another uses a username and password belonging directly to that service. Ask your provider whether both routes are active and how each is protected.
Single sign-on, or SSO, lets people use one sign-in to reach several applications. In a common arrangement, each application relies on an identity provider to verify the user. Don't infer that every route uses it because the button appears on the page. Equally, don't assume a separate-looking page bypasses protection. Have the provider trace the actual arrangement.
In a fictional workshop, the owner could use SSO for the booking service while a temporary receptionist has a separately created account. Both need to appear in the review. Checking only the owner's account would leave an unanswered question.
Compare the people with the policy
Ask for the current account list and the configuration that protects those accounts. Include administrators, ordinary staff and any relevant guest access. Check departures and temporary accounts against what the business expects to see.
Useful questions include:
- Which policy or setting requires MFA for these users?
- Which services does that setting cover?
- Are any people, groups or sign-in routes excluded?
- Who approved each exclusion, and what protects the account instead?
- What happens when a new account is created?
Keep uncertainty visible. “Needs checking with the provider” is a better working note than a tick that nobody can explain. Don't remove unfamiliar accounts or exclusions during the meeting. Establish what depends on them and arrange a controlled change.
Read the result with someone who understands it
For Microsoft Entra, the identity service behind many Microsoft 365 sign-ins, the old per-user MFA status can be misleading. Microsoft explains that a status of Disabled can be expected when security defaults or Conditional Access provides the protection. Conditional Access is Microsoft's policy system for deciding what a sign-in must satisfy.
An absent phone prompt isn't proof of failure either. Microsoft's MFA sign-in reporting guidance explains that a previous MFA result can be accepted. It advises examining authentication details and the underlying method, rather than relying on one summary field. Newly recorded details can also take time to become complete.
Ask your provider to walk through a known, authorised sign-in and explain the relevant policy and event together. Record the date, service and account being checked. You don't need to copy the user's secret codes or publish screenshots of the log.
One demonstration helps explain the setup. It doesn't prove that every account and route is covered. Follow it with a review of the full intended coverage and any exceptions.
Ask about older connections and automated jobs
Some older connections use basic authentication, which cannot satisfy MFA. Microsoft's legacy authentication guidance explains how to identify this traffic. Ask your provider to investigate any remaining use and plan a supported replacement without breaking a business process.
Be precise about accounts used by software. A user account running an automated job and a dedicated application identity are different arrangements. Don't assume that naming an account “service” makes it exempt from the requirements. Have the provider identify its type, authentication and access, then resolve scheme questions with your Certification Body.
Likewise, an emergency account needs an understood recovery design and protections. Don't add a broad exclusion just because an online checklist mentions one.
Leave the meeting with a short action list
For each gap, record the service, the unanswered question, the person resolving it and the date you'll check again. Start with the service you've examined and then work through the rest of your cloud list.
Before making sign-in changes, agree how users will enrol, how someone with accessibility needs will be supported and what happens if a person loses their usual authentication device. Tell staff where genuine help comes from so a confusing setup message doesn't push them towards an unsafe workaround.
Use our cloud scope guide if you're still finding the services people use. A useful review ends with an explanation your business can understand and a named owner for anything that remains unresolved.