Real Product / Anonymized: official SCOUTz Studio client-safe report capture; screenshot values are not current customer results This is an interface illustration, not evidence of the technical condition discussed in this article.
MFA registration is not proof of Microsoft 365 MFA enforcement. An MSP must distinguish a registered authentication method, permission to use that method, the policies that apply to an account, and evidence from the sign-ins being assessed.
MFA registration is not proof of Microsoft 365 MFA enforcement. An MSP must distinguish a registered authentication method, permission to use that method, the policies that apply to an account, and evidence from the sign-ins being assessed.
TL;DR
- Microsoft 365 MFA enforcement requires policy and sign-in evidence, not a registration count alone.
- Kaseya's 2026 report describes 56% of monitored accounts as having MFA disabled or inactive.
- The report's 27% organizational enforcement figure uses a different denominator from its account-level figure.
- SCOUTz supports authorized evidence review; unread controls remain unknown, not compliant.
- The SCOUTz Microsoft 365 assessment uses customer-approved, read-only evidence. A public-domain review cannot establish internal MFA coverage.
What should MSPs verify about MFA registration versus enforcement?
Verify the question at each layer. Do not collapse four different observations into one green status.
| Evidence layer | Question answered | Suitable evidence | What remains unproven |
|---|---|---|---|
| Registration | Has a method been registered? | Registration details | The method is required during access |
| Capability | Is a registered method enabled for MFA use? | Authentication-method capability reporting | Every relevant sign-in requires MFA |
| Policy coverage | Does an effective policy require MFA for this scenario? | Applicable policy scope, state, conditions and exclusions | Every historical session met the requirement |
| Observed authentication | What happened during a specific access event? | Relevant sign-in and authentication records | Protection outside the reviewed population and period |
Best for a defensible client statement: all applicable layers, assessed against a stated population and window. Registration reporting is useful inventory, but it is a weak substitute for enforcement verification.
Why this matters
An owner asks whether MFA is on. A technician sees registered methods. A salesperson writes that the environment is protected. The sentence changed meaning twice without anyone necessarily changing the underlying configuration.
In a 2026 security review, the operational question is not whether a chart is mostly green. It is whether the evidence supports the particular assertion your buyer, insurer, or management team is about to rely on.
This distinction does not make MFA less important. It makes the claim precise enough to test. A useful report says which identities, resources, policies, and dates were examined; it does not promise that one registration export describes every path into the environment.
What do the Kaseya MFA statistics actually say?
Kaseya's 2026 SaaS Security Report analyzed activity collected throughout 2025 from 50,723 SMB environments and 6,257,326 end-user accounts, including guests. It reports that 56% of monitored accounts had MFA disabled or inactive and 27% of monitored SMBs actively enforced MFA policies.
Those percentages use different units:
The 56% figure describes accounts in the monitored dataset. The 27% figure describes organizations in the monitored dataset. The 73% figure is the organizational complement presented as not enforcing policies. You cannot subtract 27% from 56% to calculate a protection gap. Nor can you say 73% of all small businesses everywhere have no MFA. The dataset reflects organizations using SaaS Alerts, with its observed configurations and coverage.
Use these 2026 report figures to justify asking a better question. They do not establish the state of a prospect you have not reviewed, and they do not turn an account with missing evidence into a confirmed unprotected account.
What Microsoft means by MFA capable
Microsoft's Authentication Methods Activity documentation describes MFA-capable users as users who are both registered for a strong authentication method and enabled by policy to use that method for MFA. Capability is therefore more specific than simply possessing any registered contact method.
The same documentation separates Registration from Usage. That distinction matters: knowing a method is available is different from examining authentication requirements and methods used during access.
Microsoft also documents reporting limitations. Authentication-method data is not real-time and can reflect latency of up to 36 hours, with exceptions. Some usage views exclude third-party MFA enforcement or sign-ins where a token claim satisfied the requirement.
A 2026 assessment should therefore record both the observation date and the source's update window. A fresh screenshot of a delayed report is not fresh evidence of every underlying change.
Start by writing the assertion you need to test
Do this before choosing an export. A broad question produces a broad claim that is difficult to substantiate.
Examples of appropriately bounded assertions include:
Specified administrator identities are included in the relevant enforcement policies. A defined user population has registered methods and applicable policy coverage. A sampled sign-in met the documented authentication requirement. An exclusion has a named owner, purpose, and review date. These are review objectives, not claims that the client's configuration already meets them. If an insurer or contract uses a specific definition, assess that wording rather than substituting your preferred dashboard metric.
Avoid the unbounded sentence that MFA is enforced everywhere unless the reviewed scope actually supports it. If coverage is partial, say partial. If a source was unavailable, say not assessed.
A read-only MFA verification workflow
1. Define the identity population
Separate employees, administrators, guests, and non-human identities. A user-oriented MFA percentage does not describe application authentication or every automated workload.
Record:
Which tenant and identity groups are in scope. Whether guests are included. How administrator identities are identified. Which disabled or recently deleted identities are absent from source reports. Which non-human identity controls require a separate review. Microsoft documents that disabled and soft-deleted users are not listed in user registration details. That is a reporting boundary, not permission to forget those identities elsewhere in the assessment.
2. Record registration and capability separately
Use authorized evidence to identify available methods and reported capability. Preserve the report labels rather than renaming everything enabled.
Keep a source and collection date beside each state. If different sources disagree, investigate their populations, freshness, and definitions before selecting the more reassuring answer.
Use three explicit outcomes:
- Evidence supports the stated registration or capability condition.
- Evidence shows a condition needing review.
- The condition could not be assessed from the available source.
- Do not use a blank field as shorthand for not configured. Blank can mean unavailable, excluded, delayed, or unread.
3. Examine applicable enforcement policies
Review the policy mechanism actually in use and how it applies to the stated access scenario. A policy's existence is not the same as effective coverage.
Capture scope, state, conditions, exclusions, and the authentication requirement. Verify whether the policy is effective rather than merely being evaluated or documented as an intended change.
Keep configuration review separate from modification. This article is an evidence workflow, not authorization to edit a client's sign-in controls. A poorly planned enforcement change can interrupt legitimate access, so implementation needs its own approved plan, validation, and recovery procedure.
4. Inspect relevant sign-in evidence
Use sign-in evidence to test the assertion within the source's supported period. Inspect authentication details and context rather than counting visible prompts.
A user not seeing a new prompt does not, by itself, prove MFA was bypassed. Conversely, a successful sign-in does not by itself prove every required control worked. Interpret the recorded requirement and satisfaction evidence.
State the exact limitation: a sampled event supports a conclusion about that event. It does not certify every session or application outside the review.
5. Resolve disagreements before issuing the report
If capability, policy coverage, and observed authentication disagree, preserve the disagreement. Reconcile timestamps, account type, resource, source coverage, and reporting behavior.
Record unresolved items as open questions with an owner. Avoid averaging incompatible percentages into a reassuring combined score.
SCOUTz Microsoft 365 evidence review can help organize supported tenant observations with their sources and limits. SCOUTz does not make missing evidence equivalent to protection, and an assessment snapshot is not continuous surveillance.
How to explain the result to a business owner
A good summary answers three questions: what was checked, what was established, and what decision follows.
Illustrative wording, not a customer result: The review found registered authentication methods for the specified population, but effective policy coverage could not be established for the excluded access scenario. The next step is to validate that scenario with the authorized administrator before making a tenant-wide enforcement claim.
That statement is less dramatic than declaring the business exposed. It is also more actionable than declaring everything secure.
Use an owner-facing table:
| Review result | Meaning for the decision | Next action |
|---|---|---|
| Registration supported, enforcement unread | Readiness is visible; coverage remains unknown | Obtain the missing authorized evidence |
| Policy exclusion confirmed | A defined exception exists | Validate purpose and approved compensating controls |
| Sampled authentication satisfies requirement | The reviewed event supports the assertion | Retain evidence and disclose sample limits |
| Contradictory sources | The conclusion is unresolved | Reconcile definitions and timestamps |
None of these rows establishes a breach. A protection gap and an account compromise are different findings requiring different evidence.
Common mistakes in a 2026 MFA assessment
Using the survey as a prospect diagnosis. Kaseya's monitored population does not establish a specific account's state. Show the customer their evidence, not an industry percentage presented as their result.
Confusing registration with requirement. Registration establishes availability; enforcement concerns access requirements under the applicable controls.
Treating missing logs as an uneventful period. Missing visibility limits the conclusion. It does not establish the absence of suspicious or noncompliant access.
Counting guests without understanding the authentication boundary. External identities can involve different identity providers and trust arrangements. Review the actual supported evidence before describing a local registration gap as a bypass.
Applying user MFA language to every workload identity. Application authentication needs its own credential, permission, ownership, and activity review. A human-user metric does not settle that question.
What proof should the final evidence packet contain?
Retain the assertion, population, source dates, applicable policy evidence, relevant authentication records, limitations, and the reviewer's interpretation. Protect the packet because identity and configuration evidence can itself be sensitive.
For each open issue, name the next evidence required and the responsible party. For each completed change, preserve both the implementation record and a new observation of the resulting condition. A ticket closure is not the same as verification.
SCOUTz prospect intelligence keeps dated evidence attached to the conversation; the MSP remains responsible for technical judgment and the client-facing assertion. Use separate records for the source observation and the business recommendation so later reviewers can examine either without losing context.
SCOUTz is suited to MSPs preparing evidence-led Microsoft 365 conversations, not to declaring universal protection from an incomplete snapshot. That boundary is part of the value of the review.
Sources and scope
Kaseya, 2026 SaaS Security Report, pages 5, 10–11, and 23. Observational SaaS Alerts dataset collected January–December 2025; not a representative census of all SMBs. Microsoft Learn, Authentication Methods Activity, reviewed October 14, 2026. Used for capability definitions, report separation, and reporting limitations.
FAQ
Does registering Microsoft Authenticator prove MFA is enforced?
No. Registration identifies an available method. Enforcement requires evidence that the relevant access policies apply and the assessed sign-ins satisfy the requirement.
What does MFA capable mean in Microsoft reporting?
Microsoft describes MFA-capable users as registered for a strong method and enabled by policy to use that method for MFA. Capability alone does not establish coverage for every access scenario.
Can a domain scan show Microsoft 365 MFA enforcement?
No. Public-domain evidence cannot establish internal tenant enforcement. Customer-authorized tenant evidence is required for that review.
What does Kaseya's 27% MFA figure measure?
It describes monitored SMBs actively enforcing MFA policies in Kaseya's 2025 dataset, reported in 2026. It is an organizational figure, not the proportion of protected user accounts.
Is a missing MFA prompt proof of a bypass?
No. Review the authentication requirement, how it was satisfied, and the surrounding session evidence. Prompt visibility alone is insufficient.
Can SCOUTz prove every account is protected?
SCOUTz organizes supported, customer-approved evidence with its source and limits. Unread evidence remains unknown, and a bounded review cannot prove protection outside its assessed scope.
One last thing
The strongest MFA report is not the one with the largest green percentage. It is the one whose conclusion still means the same thing when a technician, owner, and independent reviewer read it.
To evaluate the SCOUTz evidence workflow with a real prospect, Join Open Beta.
Related guides
Outside-in estimates versus tenant evidence
Explore the relevant SCOUTz workflow · Review a sample report · Join Open Beta