What this check looks at
Checks for a Conditional Access policy that blocks authentication transfer (moving a signed-in session to a phone by QR code) for all users and all resources.
Authentication transfer lets someone signed in to an app on a computer carry that session to the same app on their phone by scanning a QR code, without signing in again. It is a Conditional Access authentication flow, alongside the device code flow, and Microsoft Entra ID allows it by default.
This check applies where the tenant has Conditional Access (Entra ID P1). It looks for a policy that targets all users and all resources, includes Authentication transfer under the authentication flows condition, and blocks access. It passes when such a policy is On and warns when it is only in report-only mode. The check fails when there is none, or when the only such policy covers some users or some apps.
The session being transferred has already passed MFA, so the phone that receives it does not have to. Someone who persuades a user to scan a QR code, or who has a moment at an unlocked computer, can move that session to a device the organisation does not manage.
Why it matters
Authentication transfer hands a session that has already passed MFA from one device to another with a QR code. An attacker who tricks someone into scanning one, or who briefly reaches an unlocked computer, gets a signed-in session on their own phone without passing MFA again. Few organisations rely on it.
At a 40-person firm, a visitor waiting in a meeting room is left alone with a signed-in laptop for a few minutes. Opening Outlook and the transfer prompt, they scan the QR code with their own phone and leave with the user’s mailbox on it, MFA already satisfied, until the session is revoked.
Very few organisations use authentication transfer for anything they would miss; blocking it costs almost nothing. CIS Microsoft 365 Foundations Benchmark v7.0.0 5.2.2.17 asks for authentication transfer to be blocked for all users and all resources, and NIST CSF PR.AA-03 supports it.
How to fix it
Where: Entra admin centre → Entra ID → Conditional Access
Before you start
- Filter the sign-in logs on Original transfer method: Authentication transfer over the last 30 days to find anyone who uses it.
- If a policy already blocks the device code flow for all users and all resources, tick Authentication transfer in the same Authentication flows condition instead of creating another.
- Confirm two emergency access (break-glass) accounts exist and exclude them from the policy, so a mistake cannot lock every administrator out.
- Create the policy in report-only mode first and review its results in Entra ID sign-in logs (Conditional Access tab) for at least a week.
Step by step
- Look for any use in the sign-in logs. In the Microsoft Entra admin centre, go to Entra ID > Monitoring & health > Sign-in logs, set the range to the last 30 days and filter on Original transfer method: Authentication transfer. Note any accounts that use it and why.
- Create the policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy and name it "Block authentication transfer". Under Users, include All users and exclude your emergency access accounts. Under Target resources choose All resources. Under Conditions > Authentication flows, set Configure to Yes and tick Authentication transfer. Under Grant choose Block access, set Enable policy to Report-only and select Create.
- Or add it to the device code policy. If a policy already blocks the device code flow for all users and all resources, you can tick Authentication transfer in the same Authentication flows condition instead of creating a second policy; the check reads either.
- Review the report-only results. After a week, open the sign-in logs again and check each authentication transfer sign-in’s Report-only tab: only the accounts you expected should show Report-only: Failure.
- Switch the policy on. Open the policy, set Enable policy to On and select Save. The finding clears at the next assessment.
What users will notice
None for most people. Moving a signed-in app from a computer to a phone by scanning a QR code is refused.
How to confirm it worked
The policy state is On and an authentication transfer attempt from a test account is refused, with the policy named in the sign-in log.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.a Identity verification, authentication and authorisation |
| DSPT | Standard 4: Managing data access |
| NIS2 | Art. 21(2)(j) Multi-factor authentication and secured communications |
| Microsoft Cloud Security Benchmark | IM-7 Restrict resource access based on conditions |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| NIST SP 800-171 | 3.5.3 Use multi-factor authentication |
| CMMC Level 2 | IA.L2-3.5.3 Multifactor Authentication |
| ISO 27001:2022 | A.8.5 Secure authentication |
| CIS M365 | 5.2.2.17 Ensure authentication transfer is blocked |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1)4.8 Uninstall or disable unnecessary services on enterprise assets and software (IG2) |
| NIST CSF 2.0 | PR.AA-03: Users, services, and hardware are authenticated |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Block authentication flows with Conditional Access (Microsoft Learn)