MFA in Microsoft 365: deployment with Entra ID

How to distinguish a registered user from a truly protected access

Implementing MFA in Microsoft 365 requires checking two different things: that the person has an appropriate method and that the policy requires it for the planned accesses. The Microsoft Authenticator registration, by itself, does not demonstrate this requirement. The review should relate the user, the application, the access condition, and the evaluation result that appears in the login logs.

A useful test is to use a pilot account and walk through the applications the department actually uses. We review what policy has intervened, what method has been accepted and what exclusions exist. The absence of a new prompt on the screen should not automatically be interpreted as a failure: there may be a valid previous session or authentication. The analysis must rely on the record, not just what the user remembers.

The result is documented by scenario. Access from a managed device may follow different conditions than from a personal computer, and an administrative account may require more stringent protection. This detail helps explain why two users see different behavior without turning each difference into a cobbled-together exception that weakens the design.

Prepare for method loss before it occurs

Recovery is part of deployment. If an employee loses their phone or changes devices, the support team needs to verify their identity and restore their authentication capability through an authorized procedure. Resolving the incident by disabling untracked controls creates an exception that may remain open long after the user returns to work.

It is a good idea to try this procedure with a test account and measure whether the instructions allow the recovery to be completed. Who can intervene, what evidence is recorded and how the operation of the new method is confirmed must be defined. Emergency accounts also require their own design, supervision and periodic checks so that their availability does not depend on the same failure they are intended to resolve.

What is MFA in Microsoft 365

Multi-Factor Authentication means requiring more than one piece of evidence before accepting an authentication. Normally we talk about factors belonging to different categories:

In Microsoft 365 the authentication decision is fundamentally made through Microsoft Entra ID. That means the same policies can protect: Exchange Online, SharePoint, OneDrive, Teams, Azure, SaaS applications integrated with Entra and many enterprise applications. MFA does not necessarily mean “entering a code.” A passkey or Windows Hello for Business can provide multi-factor authentication without the user entering a password and then an SMS code.

In fact, Microsoft’s current evolution is progressively oriented towards: passwordless, phishing-resistant authentication. Official reference: Microsoft – Microsoft Entra multi-factor authentication.

Microsoft’s mandatory MFA in 2026

Microsoft is enforcing MFA for certain administrative experiences regardless of whether an organization has created its own Conditional Access policy. Phase 1. Deployment began in 2024 for operations conducted from: Azure Portal, Microsoft Entra Admin Center and Microsoft Intune Admin Center. Since February 2025, it has been progressively expanded to: Microsoft 365 Admin Center. Phase 2. From the October 1, 2025, Microsoft began the second phase for certain management operations performed by: Azure CLI, Azure PowerShell, Azure Mobile App, Infrastructure as Code tools, SDKs and REST endpoints of the control plane.

It does not affect all operations in the same way. Microsoft documentation distinguishes in the second phase between certain operations: Create/Update/Delete and read operations. It also affects emergency accounts. Break-glass accounts are not automatically exempt from this platform requirement. They must have a method capable of satisfying the mandatory MFA. Workload identities.

Managed identities and service principals are not affected in the same way by Microsoft’s interactive MFA requirement. This reinforces a fundamental recommendation: automations should not use user accounts. Official reference: Microsoft – Mandatory MFA for Azure and admin portals.

Microsoft’s mandatory MFA does not mean all users have MFA for Microsoft 365

This distinction is critical. Example. Microsoft can require MFA from an administrator when they enter: admin.microsoft.com but that does not prove that a standard user has mandatory MFA when accessing: Outlook, SharePoint, or a SaaS application. That is why our own policy is still necessary. The organization must decide whether to use: Security Defaults or Conditional Access. We should not depend solely on Microsoft enforcement.

Its goal is to protect specific Microsoft administrative services. Our strategy must protect: users, applications, data, sessions, devices.

How to design a modern MFA architecture

The MFA architecture begins by delineating who and what applications you protect. Typical staff access, administrative privileges, and relevant external cases should be included. For each group, the intended authentication method and the condition requiring it are documented. This relationship makes it possible to detect an application that has been left out of control even if its users have registered a second factor.

The selection of methods must consider risk and operation. An administrator who can change organization-wide settings needs different protection than may be sufficient for other access. When a specific authentication strength is required, the pilot must confirm that people have a method that meets it and can use it on their devices.

The requirement is implemented using the appropriate model for the environment, such as Security Defaults or Conditional Access when its requirements are available. Scope, exclusions and registrations are checked before extending a policy. Exceptions need a cause and a review; Maintaining them solely because a user had difficulty during the pilot turns a temporary incident into a permanent protection difference.

Recovery and monitoring complete the design. There should be a procedure for losing or replacing a credential and a person to review access failures, method changes, and uncovered accounts. The architecture is validated when the employee can work as intended and the IT team can explain, with records, what requirement protected that access.

Security Defaults vs Conditional Access vs MFA per user

General recommendation. For a small organization that does not have Entra ID P1: Security Defaults are better than no consistent MFA strategy. For a company that needs to define exceptions, applications, devices, or authentication strengths: Conditional Access.

Required licenses

Do not design based on the license name alone. Before budgeting for a migration to advanced methods, it is worth checking: what SKU each population has and what functionality it really needs.

Assessment before activating MFA

Before introducing enforcement we need to identify what can be broken.

Authentication Methods Policy: Where methods are currently managed

Modern method management is done from: Microsoft Entra Admin Center → Entra ID → Authentication methods → Policies. From here we can control. Passkey/FIDO2, Microsoft Authenticator, Temporary Access Pass, OATH and other supported methods. We can also define scope. Not all methods need to be available to the entire company.

Enforcement and method are two different things. Authentication Methods Policy defines: what credentials users can use. Conditional Access defines: What level of authentication is required to access. Official reference: Microsoft – Manage authentication methods.

Legacy MFA and SSPR policies should no longer be the focus of design

For years Microsoft managed some methods from separate configurations of: MFA, Self-Service Password Reset. That model has been replaced by the Authentication Methods Policy. Important date. From the September 30, 2025, methods should no longer be managed by legacy MFA and SSPR policies. Microsoft provides migration. In: Authentication methods → Policies → Manage migration we can review and consolidate the configuration.

Why it’s worth checking it out. In old tenants we can find: historical configurations, per-user MFA, Authentication Methods Policy, Conditional Access. If no one understands what each layer controls, the operation becomes very difficult. Official reference: Microsoft – Migrate authentication method policies.

Not all MFA methods offer the same protection

MFA does not mean phishing-resistant MFA. An attacker with an AiTM infrastructure can attempt to steal a session even if the user enters a password and then a code. FIDO2 credentials are cryptographically linked to the legitimate service, which significantly changes this risk.

Microsoft Authenticator and number matching

Microsoft Authenticator remains a practical option for many users. Number matching. Authenticator push notifications currently use number matching. The user must relate the request to the login they are doing. This reduces MFA fatigue. The old pattern: “Approve/Deny” repeated until the user accepts was more susceptible to attacks of fatigue. Even so, we should not teach how to “pass MFA.”

The correct training is: If you are not trying to log in, reject the request and let them know. Official reference: Microsoft – Number matching.

System-preferred authentication: Microsoft introduces strongest method first

Traditionally the user had a default MFA method. Microsoft is evolving towards system-preferred authentication. How it works. Entra reviews the methods registered by the user and presents first the method it considers strongest. Example. The user has: SMS, Authenticator. Instead of prioritizing SMS simply because it was the method you chose years ago, the system can introduce Authenticator. Microsoft-managed state.

Microsoft is gradually rolling out this behavior during 2026. Current documentation indicates that Microsoft-managed behavior is being rolled out progressively until August 2026. This affects the assessment. We should not depend exclusively on: “what method has the user selected as the default?” We must also analyze: which methods are registered and which one can actually be used by the system. Official reference: Microsoft – System-preferred authentication.

Passkeys/FIDO2: towards phishing-resistant authentication

The passkeys They use public key cryptography. The private key remains associated with the authenticator and the application stores the corresponding public key. Fundamental advantage. The credential is associated with the legitimate origin. That means a phishing page that visually mimics Microsoft can’t simply capture and reuse the credential. Can be used as MFA. When a passkey is combined with local unlocking using: PIN or biometrics can satisfy corresponding multi-factor requirements.

For whom? Especially interesting for: administrators, management, finance, HR. HH., privileged users and high-risk population. Official reference: Microsoft – FIDO2 Passkeys.

Synchronized Passkeys vs. Device-Linked Passkeys

In 2026 it is important to differentiate different models.

Microsoft difference by profile. Microsoft’s current guidance recommends assessing: device-bound credentials for administrators or especially privileged users and: synced passkeys for many standard users when the risk model allows it. Recovery changes. A synced passkey can greatly simplify the problem of losing a device. A physical security key needs a different plan: second key, TAP or controlled recovery procedure.

Microsoft Entra passkey in Windows

Microsoft currently provides Microsoft Entra passkeys on Windows. In August 2026 this functionality is documented in public preview. What does it allow? Create a passkey linked to the device within the local Windows Hello container. The user can then authenticate using: biometrics or Windows Hello PIN. Difference vs. synced passkey. The credential remains on the device and is not synchronized.

Not to be confused with Windows Hello for Business. They are technologies related to FIDO/passwordless, but have different implementation models and requirements. Official reference: Microsoft – Microsoft Entra passkey on Windows.

Authentication Strengths: MFA does not have to accept any second factor

Conditional Access may simply require: Requires multi-factor authentication. But we can also use: Require authentication strength. This allows us to define what level we need.

Built-in phishing-resistant MFA. Microsoft includes a predefined strength for phishing-resistant methods. Custom authentication strengths. We can also build specific profiles, for example limiting: specific types of FIDO2/passkey or certificates. Official reference: Microsoft – Authentication strengths.

Option 1: Security Defaults

Security Defaults provides a free identity baseline. Currently includes.

Important detail. Security Defaults does not necessarily mean: “every user must complete MFA at absolutely every login.” Microsoft decides when to ask for additional authentication from end users based on different signals. Administrators. Covered administrative roles receive more stringent requirements. When it fits. Security Defaults may be appropriate if: We don’t have Entra P1/P2, we don’t need exceptions, we don’t have complex architecture.

When it doesn’t fit. If we need: groups, applications, trusted locations, devices, authentication strengths, service-account exceptions or differentiated controls. In that case we should evaluate Conditional Access. Official reference: Microsoft – Security Defaults.

Security Defaults and Device Code Flow: important change from July 2026

The Device Code Flow It is used on applications or devices that have limited ability to log in directly. It can also be abused for phishing. An attacker can try to convince a user to enter legitimate code on a Microsoft page and end up authorizing a session controlled by the attacker. Security Defaults blocks it. When Security Defaults is enabled, requests that use Device Code Flow are blocked.

New tenants. From the July 1, 2026, new Microsoft Entra tenants include this block as part of Security Defaults. Before activating. We must check if there are: Old CLIs, devices, scripts, or applications that depend on Device Code. If we need exceptions. Security Defaults do not provide sufficient granularity. The appropriate model would normally be: Conditional Access with controlled policies.

Option 2: Mandatory MFA with Conditional Access

Conditional Access is the policy engine that allows signals to be combined before granting access. You can evaluate. user, group, role, application, location, device, risk, platform, authentication strength and other conditions. A base policy. For example:

Then we add specific policies. It is not advisable to create a single “mega-policy” with all the conditions. It is easier to maintain policies with specific objectives.

A practical Conditional Access baseline

The numbers are not the important thing. The important thing is that each policy has: a purpose, a scope, an exception, an owner.

Report-only before activating a policy

Conditional Access allows you to run policies on Report-only. This allows you to respond. What would have happened if the policy had been active? What to look for.

Review multiple profiles. web, desktop, mobile, admins, guests, automations. Don’t leave Report-only forever. It is a validation tool, not a permanent security check. Official reference: Microsoft – Conditional Access Plan.

Administrators: MFA should be the minimum, not the end goal

Administrative accounts deserve differentiated protection. Microsoft recommends phishing-resistant MFA. For top administrative roles, Microsoft recommends moving toward phishing-resistant methods. Especially sensitive roles. Among others: Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Authentication Administrator, Exchange Administrator, SharePoint Administrator and Security Administrator. Separate administrative identity. An administrator should ideally have: productivity account, separate administrative account.

Benefit. The privileged account is not used to: mail, general browsing or everyday collaboration. With PIM. When Entra P2 exists, we can add: roles eligible, temporary activation, MFA, approval, justification depending on the sensitivity of the role. Official reference: Microsoft – Require phishing-resistant MFA for administrators.

Break-glass accounts in 2026: MFA yes, unnecessary dependency no

The historical recommendation to leave an account break-glass only with a password no longer correctly represents the current scenario. Microsoft recommends at least two accounts. They must be: cloud-only, .onmicrosoft.com domain, Global Administrator, emergency use only. They must satisfy the mandatory MFA. Microsoft recommends using methods such as: FIDO2/passkey or certificate-based authentication. But they must be excluded from Conditional Access which can block them.

This is not contradictory. One thing is: have a strong credential capable of satisfying MFA. Another different one is: make your access depend on a corporate policy that could be precisely the cause of the block. Example. It doesn’t make much sense that the only emergency account requires: Intune compliant device, office IP, Authenticator installed on the same administrator’s mobile.

A crash of any of those dependencies would eliminate their usefulness. Current good practices.

Official reference: Microsoft – Emergency access accounts.

Registration Campaign: migrate users to better methods

There is no need to wait for a big migration for users to improve their method. Microsoft Entra has Registration Campaign. In 2026 he can promote. Microsoft Authenticator or Passkey/FIDO2. Only one goal at a time. Currently a campaign cannot simultaneously request: Authenticator, passkey. We must select the objective of the campaign. We can segment. For example:

Microsoft-managed. Microsoft also manages recommended values for these campaigns and is progressively evolving the recommendation towards passkeys in certain tenants. Official reference: Microsoft – Registration Campaign.

Temporary Access Pass: the bridge between onboarding and strong authentication

Temporary Access Pass is a temporary credential issued by an administrator. It may be from. single use or multiple uses over a limited period according to policy. Use cases.

Configuration. From: Entra ID → Authentication methods → Policies → Temporary Access Pass. Currently we can define. minimum duration, maximum duration, default duration, length and whether it can be reused. TAP is not a permanent temporary password. There must be a procedure for: user identification → issuance → secure delivery → registration → closure. Official reference: Microsoft – Temporary Access Pass.

MFA project needs a recovery procedure

The question is not whether any user will lose their mobile phone. The question is when. Scenarios. Lost mobile, replaced phone, broken security key, remote employee, Authenticator removed or device change. Process.

Do not disable MFA to recover a user. A common bad practice is: “We took away MFA ten minutes.” TAP provides a much more controlled mechanism.

MFA in BYOD: authentication does not equal data protection

MFA more confidently demonstrates who is trying to access. It does not necessarily answer: what can that device do with the data afterwards? We can combine.

Do not demand compliant device indiscriminately. A policy of: All users, All apps, Require compliant device Without checking BYOD you can immediately block: personal mobile phones, external equipment and even certain integrations.

Guest Users and MFA

B2B guests should also be part of the design. An option. We can require MFA in our tenant. Another. In certain scenarios we can rely on the MFA performed on the origin tenant by: cross-tenant access settings. Authentication strengths. They can also be used with external users, but we must check which method can be recognized from the origin tenant. Avoid duplicating prompts unnecessarily.

Good B2B design allows you to maintain security without forcing the guest to register unnecessary additional credentials when we can properly trust your organization.

Service accounts: excluding them from MFA forever does not solve the problem

A service account based on: username, stored password It’s technical identity debt. Examples. PowerShell scripts, integrations, ERP, backups, SMTP, scheduled tasks and old tools. The solution should not be. “serviceaccount@empresa.com is out of MFA indefinitely.” Objective. Migrate to: managed identity, service principal, certificate authentication, workload identity, or modern application-specific mechanism. If we temporarily need an exception.

Workload identities: identity for machines, not users pretending to be machines

Microsoft clearly differentiates: user identities and workload identities. Examples of workload identity. managed identities and service principals. Advantage. They do not need to respond interactively to an Authenticator prompt. Conditional Access for workload identities. Microsoft also has specific Conditional Access capabilities for certain workload identities. Do not reuse user policies. The risk model is different.

Block legacy authentication

Protocols that do not support modern authentication cannot complete MFA in the same way as modern OAuth. Historical examples. legacy clients, POP/IMAP with Basic Authentication, legacy ActiveSync, and applications that use credentials directly. Security Defaults already blocks legacy authentication. With Conditional Access it is convenient to have a specific policy. Before blocking. Review sign-in logs using: Client app / legacy authentication to locate dependencies.

Do not confuse protocol with authentication. IMAP or POP can exist in modern scenarios with OAuth. The historical security problem is mainly: Basic Authentication.

SMTP, devices and applications

MFA often discovers email dependencies that no one has documented. Examples. printers, scanners, ERP, CRM, monitoring, internal applications and forms. Before enforcement. Document for each issuer:

A user account with a password should not be the universal solution. The exact alternative depends on the use case.

How to correctly check which users are MFA ready

We should not analyze coverage only through the state: Disabled / Enabled / Enforced from the old per-user MFA page. In fact. When we use: Security Defaults or Conditional Access, it is normal for the per-user state to appear like: Disabled. That doesn’t mean there’s no MFA. Enforcement comes from another layer. Authentication Methods Activity. Microsoft Graph has the resource: /reports/authenticationMethods/userRegistrationDetails Especially useful properties.

Recommended PowerShell for Inventory

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "AuditLog.Read.All"

$MfaStatus = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

$MfaStatus |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  IsAdmin,
                  IsMfaRegistered,
                  IsMfaCapable,
                  IsPasswordlessCapable,
                  MethodsRegistered,
                  IsSystemPreferredAuthenticationMethodEnabled |
    Export-Csv "C:\Temp\MFA-Registration-Details.csv" `
        -NoTypeInformation `
        -Encoding UTF8

Users who are not MFA capable

$MfaStatus |
    Where-Object {
        $_.IsMfaCapable -eq $false -and
        $_.UserType -eq "member"
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  IsAdmin,
                  MethodsRegistered

Administrators without MFA capability

$MfaStatus |
    Where-Object {
        $_.IsAdmin -eq $true -and
        $_.IsMfaCapable -eq $false
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  MethodsRegistered

Passwordless users

$MfaStatus |
    Where-Object {
        $_.IsPasswordlessCapable -eq $false
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  MethodsRegistered

Why this is better than Get-MgUserAuthenticationMethod. Listing authentication objects can be used for detailed operations on a user. But for a global assessment we need to answer directly: Is it registered? Is it MFA capable? Is it passwordless capable? The log report already offers these properties. Official reference: Microsoft Graph – User registration details.

Sign-in logs: check actual enforcement

A user may have Authenticator registered and not be correctly protected by the policy we expected. That is why registration and enforcement must be reviewed separately. In each sign-in we can analyze. Authentication Details, Conditional Access, client, application, IP, device, location and risk when license exists. Questions.

Don’t always wait for a prompt. Not seeing an MFA screen on every startup doesn’t necessarily mean that MFA is being bypassed. There may be: SSO, valid token, authentication strength already satisfied, or a passwordless multi-factor credential.

Useful metrics after deployment

Implementation roadmap in 90 days

Days 1–15: discover.

Days 16–30: Prepare for safety and recovery.

Days 31–45: pilot.

Days 46–60: enforcement.

Days 61–75: expand passwordless.

Days 76–90: govern and measure.

Common mistakes when implementing MFA in Microsoft 365

Checklist before activating mandatory MFA

Frequently asked questions about mandatory MFA in Microsoft 365

Does having Authenticator configured mean MFA is applied?

Not necessarily. Registration confirms that an authentication method is available, while the requirement depends on policies and specific access. Review your login logs and check which applications and users are included. Existing exclusions and sessions must also be examined to correctly interpret the test result.

Should we ask for a second factor in each user action?

The experience depends on existing valid sessions, policies, applications and authentication tokens. The objective is to meet the requirements defined for each access, without generating unnecessary prompts. If behaviour differs from the design, investigate the sign-in evaluation before changing controls or creating exclusions.

Where should you start an MFA implementation?

Start with an inventory of users, authentication methods, applications and dependencies, then run a representative pilot. Prepare method registration and account recovery before expanding the rollout. Review the required authentication strength separately for privileged accounts and access that carries greater risk.

How should accounts that use apps or devices be treated?

First you identify how they authenticate and whether the integration supports an appropriate model for applications. It is not advisable to resolve this by leaving a user account excluded indefinitely without analyzing its use. Each exception must have a responsible person, reason and review plan, while an alternative compatible with the application or device is studied.

Final Recommendations: Mandatory MFA is no longer just about installing Microsoft Authenticator

Implement Mandatory MFA in Microsoft 365 remains one of the most important improvements an organization can make to its identity security. But the model has evolved. Microsoft already requires MFA in different portals and administrative tools, and this obligation will continue to be part of the platform’s operation. However, that does not eliminate the need to design our own strategy.

Security Defaults provides good basic protection when Entra ID Premium does not exist and we do not need complex exceptions. Conditional Access provides the control necessary when we want to differentiate users, applications, devices, risks and authentication strengths. The next decision is what credentials we want to allow. Microsoft Authenticator remains practical for many users, but the goal for privileged accounts should move toward phishing-resistant MFA.

Passkeys/FIDO2, Windows Hello for Business, and certificate-based authentication provide options that are much more resistant to modern phishing attacks than traditional SMS or OTP. Microsoft’s evolution during 2026 reinforces this path. System-preferred authentication allows for automatic prioritization of stronger methods, and Registration Campaign can be used to progressively migrate users from weaker methods to Authenticator or passkeys. Temporary Access Pass completes that architecture by providing a controlled bootstrap and recovery path.

The correct way to design emergency accounts has also changed. Break-glass accounts are still required and Microsoft continues to recommend having at least two, but they must be prepared to satisfy mandatory MFA requirements. At the same time, they must stay out of Conditional Access policies that could block them during the incident that they should precisely help us resolve. Automations require another approach.

A user account with a password that is indefinitely excluded from MFA should not be considered a stable solution. The goal should be to migrate toward workload identities, managed identities, service principals, or certificate authentication where appropriate. Finally, we need to measure. We cannot evaluate the project by simply asking if a user appears as “Enabled” on the old MFA page. Authentication Methods Activity and Microsoft Graph allow us to know which users are MFA capable, MFA registered and passwordless capable, while the Sign-in Logs allow us to validate if the policies are really being applied.

The correct question is no longer: “Do we have MFA activated?” and it becomes: “Do all users who should be protected have an appropriate credential, is there a policy that actually requires it, can we regain access if that credential fails, and have we eliminated exceptions that allow bypassing the model?” When we can answer yes to those four questions, we have an MFA strategy and not just a configuration.

Recommended official documentation

MFA and mandatory enforcement.

• Microsoft – Microsoft Entra multi-factor authentication
• Microsoft – Mandatory MFA for Azure and admin portals
• Microsoft – Verify mandatory MFA setup

Security Defaults.

• Microsoft – Security Defaults

Conditional Access.

• Microsoft – Conditional Access overview
• Microsoft – Conditional Access Plan
• Microsoft – Require MFA for all users
• Microsoft – Require MFA for administrators
• Microsoft – Phishing-resistant MFA for administrators

Authentication Methods.

• Microsoft – Manage authentication methods
• Microsoft – Migrate authentication method policies
• Microsoft – System-preferred authentication
• Microsoft – Authenticator number matching

Passkeys and FIDO2.

• Microsoft – FIDO2 Passkeys
• Microsoft – Enable passkeys
• Microsoft – Passkeys in Authenticator
• Microsoft – Synced passkeys
• Microsoft – Passkey FAQ
• Microsoft – Entra passkey on Windows

Authentication Strengths.

• Microsoft – Authentication Strengths
• Microsoft – How Authentication Strengths work
• Microsoft – Custom Authentication Strengths

Registration and Temporary Access Pass.

• Microsoft – Registration Campaign
• Microsoft – Temporary Access Pass
• Microsoft – Deploy phishing-resistant passwordless authentication

Emergency access.

• Microsoft – Emergency access accounts
• Microsoft – Resilient access control strategy

Microsoft Graph and reporting.

• Microsoft Graph – userRegistrationDetails
• Microsoft Graph – List userRegistrationDetails
• Microsoft Graph PowerShell – Get-MgReportAuthenticationMethodUserRegistrationDetail

BYOD and Intune.

• Microsoft – App Protection Policies