Executive summary

Microsoft Edge MAM for Windows was configured correctly.

The Intune app protection policy was assigned. The Conditional Access policy requiring app protection targeted Microsoft 365. Microsoft Edge was being used on an unmanaged Windows device.

Yet the user was blocked before MAM enrollment could complete.

The blocking policy was a broad Conditional Access policy configured to block All resources while excluding Office 365 and several required service dependencies. The sign-in log showed Microsoft Edge as the client application, but the actual target resource was Microsoft Edge Auth.

That resource was not covered by the Office 365 exclusion. More importantly, its enterprise application object did not exist in the tenant, so it could not be selected as an exclusion in Conditional Access.

The resolution was to instantiate the Microsoft-managed application in the tenant by creating its service principal with Microsoft Graph:

{
  "appId": "f2d19332-a09d-48c8-a53b-c49ae5502dfc"
}

After the service principal appeared as Microsoft Edge Auth, it could be excluded from the broad block policy. The Edge work-profile authentication flow then proceeded and Windows MAM could perform its intended evaluation.

The architecture

The customer requirement was straightforward:

• Users work from personal or otherwise unmanaged Windows devices.
• Devices must not be enrolled in full MDM.
• Microsoft 365 access is allowed only through a protected Microsoft Edge work profile.
• Intune App Protection Policy protects organizational data inside Edge.
• Conditional Access blocks access that does not satisfy the approved path.

Microsoft documents Windows MAM as a way to provide protected access to organizational data through Microsoft Edge without fully managing a personal Windows device. The design relies on several connected control planes: Edge, Microsoft Entra Conditional Access, and the Intune MAM service. The MAM service synchronizes compliance state per user, app, and device to Entra Conditional Access. Microsoft: Data Protection for Windows MAM

The key word is connected.

The browser does not move directly from "unmanaged" to "MAM protected" in a single request. Authentication and MAM bootstrap dependencies must remain reachable long enough for the protected Edge profile to be established and evaluated.

The policy combination

Two different Conditional Access intentions existed:

1. A policy allowed Microsoft 365 through the Windows MAM path by requiring an app protection policy.
2. A separate defensive policy blocked All resources, with explicit exclusions for Office 365 and approved service dependencies.

At a high level, that can appear logically sound:

Block everything
        ↓
Exclude Office 365
        ↓
Evaluate Microsoft 365 through the dedicated MAM policy

But the authentication transaction did not target only Office 365.

Microsoft's documented baseline for Windows app protection targets the Office 365 resource group and the Browser client-app condition. Microsoft also recommends beginning in Report-only mode and validating policy impact before enforcement. Microsoft: Require an app protection policy on Windows devices

The broad block policy introduced an additional dependency problem: any supporting resource outside the Office 365 exclusion remained blocked.

What the user experienced

The user attempted to access Microsoft 365 from Microsoft Edge on an unmanaged Windows device.

Instead of completing the protected work-profile flow, the sign-in was denied by Conditional Access with error 53003.

The first instinct in this situation is usually to inspect:

• App Protection Policy assignment
• App Configuration Policy assignment
• Edge version and work-profile state
• Intune licensing
• User registration or stale MAM enrollment
• Device platform and client-app conditions
• Conditional Access What If results

Those checks matter, but none explains the incident if the request is blocked before the MAM service can complete its work.

The sign-in log revealed the real dependency

The sign-in event contained two different application identities:

This distinction changed the investigation.

Conditional Access evaluates access to the target resource. Although the user was ultimately trying to reach Microsoft 365, this stage of the Edge flow requested Microsoft Edge Auth. The "Block All resources" policy therefore applied to Microsoft Edge Auth.

Excluding Office 365 did not exclude Microsoft Edge Auth.

Why the resource could not simply be excluded

The next step appeared obvious: add Microsoft Edge Auth to the exclusions of the broad block policy.

But it was not available in the Conditional Access resource picker.

The Microsoft-managed application existed globally, but its local service principal had not yet been instantiated in the customer tenant. Conditional Access could not select a tenant object that did not exist.

This is where the distinction between an application definition and a service principal matters:

• The application identity is defined by its global App ID.
• The service principal is the local representation of that application in a specific tenant.
• Conditional Access resource selection depends on the resource being represented in the tenant.

Creating the service principal did not create a custom Edge application. It created the tenant-local enterprise application object for the existing Microsoft-managed application identity.

Attempt 1: Microsoft Graph PowerShell

The first implementation path used the Microsoft Graph PowerShell SDK.

Only the least-privileged delegated permission required by the create-service-principal API is needed:

Connect-MgGraph `
    -TenantId "<tenant-id>" `
    -Scopes "Application.ReadWrite.All" `
    -ContextScope Process `
    -NoWelcome

Microsoft lists Application.ReadWrite.All as the least-privileged delegated permission for POST /servicePrincipals; Directory.ReadWrite.All is a higher-privileged alternative and is not required for this operation. The signed-in administrator must also hold a supported Entra role, such as Application Administrator or Cloud Application Administrator. Microsoft Graph: Create servicePrincipal

The local session displayed this warning:

WARNING: Note: Sign in by Web Account Manager (WAM) is enabled by default on Windows.
If using an embedded terminal, the interactive browser window may be hidden behind other windows.

This message is important to describe accurately: it is an informational warning, not proof that WAM authentication failed. It indicates that the interactive sign-in UI might not be visible in the foreground. In this case, the interactive PowerShell authentication path did not complete cleanly in the working terminal.

Device code authentication was considered but intentionally not used. Microsoft supports it in Connect-MgGraph, but classifies device code flow as a higher-risk authentication method and recommends blocking it as broadly as possible except for documented, secured use cases. Microsoft: Block authentication flows with Conditional Access

If Graph PowerShell authentication is already approved and working in an organization, the service-principal operation itself is simple:

$edgeAuthAppId = "f2d19332-a09d-48c8-a53b-c49ae5502dfc"

$servicePrincipal = Get-MgServicePrincipal `
    -Filter "appId eq '$edgeAuthAppId'" `
    -Property Id,AppId,DisplayName,ServicePrincipalType

if (-not $servicePrincipal) {
    $servicePrincipal = New-MgServicePrincipal -AppId $edgeAuthAppId
}

$servicePrincipal |
    Format-List Id,AppId,DisplayName,ServicePrincipalType

The existence check matters. Re-running a create request without checking first can produce an "already exists" conflict and makes the procedure less safe to reuse.

Attempt 2: Create the service principal with Graph Explorer

Graph Explorer provided a transparent interactive path to run the same Microsoft Graph operation.

Required permission

In Modify permissions, consent to the delegated permission:

Application.ReadWrite.All

Do not request Directory.ReadWrite.All unless another operation genuinely requires it.

Request

Use:

POST https://graph.microsoft.com/v1.0/servicePrincipals
Content-Type: application/json

Request body:

{
  "appId": "f2d19332-a09d-48c8-a53b-c49ae5502dfc"
}

Microsoft's API requires the appId property and returns 201 Created when the service principal is created successfully. Microsoft Graph: Create servicePrincipal

The Conditional Access correction

After the Graph request completed, Microsoft Edge Auth appeared as an Enterprise Application and became selectable in the Conditional Access target-resource picker.

It was then added to the Exclude list of the broad "Block All resources" policy.

The final logic became:

Broad block policy
├── Include: All resources
├── Exclude: Office 365
├── Exclude: Microsoft Edge Auth
└── Grant: Block access

Dedicated Windows MAM policy
├── Target: Office 365
├── Platform: Windows
├── Client app: Browser
└── Grant: Require app protection policy

This is not a bypass of the MAM policy.

The Microsoft Edge Auth exclusion allows the prerequisite Edge authentication transaction to proceed. Access to Microsoft 365 is still evaluated by the dedicated policy that requires app protection.

Validation after the change

A successful change should be validated as a transaction, not only as a policy edit.

1. Confirm that the Microsoft Edge Auth service principal exists in Enterprise Applications.
2. Confirm that its App ID is exactly f2d19332-a09d-48c8-a53b-c49ae5502dfc.
3. Confirm that Microsoft Edge Auth is excluded only from the intended broad block policy.
4. Retest with a pilot user on an unmanaged, supported Windows device.
5. Use a fresh Edge work profile or an agreed clean test state.
6. Confirm in the sign-in logs that the Microsoft Edge Auth request is no longer blocked by the broad policy.
7. Confirm that the later Microsoft 365 request is evaluated by the intended MAM Conditional Access policy.
8. Confirm that the Intune App Protection Policy is actually applied inside the Edge work profile.

Do not treat "the page opened" as complete validation. The expected result is both access and data protection enforcement.

What did not solve the incident

Several actions could change the symptom without addressing the dependency:

• Reassigning the same Intune App Protection Policy
• Recreating the Edge profile repeatedly
• Excluding the pilot user from the broad block policy
• Disabling the block policy
• Assuming that the Office 365 exclusion includes every authentication dependency
• Adding Directory.ReadWrite.All when Application.ReadWrite.All is sufficient
• Treating the WAM warning as the root technical failure
• Switching to device code authentication simply to get past an interactive sign-in problem

These are diagnostic shortcuts, not the architectural correction.

Security and governance guardrails

1. Do not copy exclusions blindly

This exclusion was derived from an observed sign-in transaction and a confirmed Microsoft-managed App ID. Every exclusion from a block policy changes the security boundary. Validate the resource, document the dependency, and assign an owner.

2. Exclude the resource, not the user

A persistent user exclusion would allow the account to avoid the block policy across unrelated resources. A narrowly defined resource exclusion preserves the broader user control.

3. Use least privilege for service-principal creation

For delegated creation, use Application.ReadWrite.All and an administrator with an appropriate Entra role. Remove or end the privileged session after the operation.

4. Keep broad block policies in Report-only during design changes

"All resources" policies have large blast radii and hidden service dependencies. Microsoft recommends report-only validation and staged deployment for Conditional Access policies. Maintain emergency-access exclusions and monitor the effect before enforcement.

5. Record the object, reason, owner, and review date

The exclusion record should contain:

• Display name: Microsoft Edge Auth
• App ID: f2d19332-a09d-48c8-a53b-c49ae5502dfc
• Policy from which it is excluded
• Business and technical justification
• Evidence from the sign-in log
• Change ticket or incident reference
• Owner
• Review date

Reality check

"Block all, exclude Office 365" sounds simpler than it is.

Microsoft 365 access is a chain of authentication, broker, registration, application, and compliance transactions. Conditional Access evaluates resources at different points in that chain. A dependency that is invisible in a portal design session becomes very visible in the sign-in logs after enforcement.

The policy engine behaved exactly as configured.

The design had not represented the complete authentication path.

Final architect recommendation

Do not begin this type of incident by rebuilding MAM.

Begin with the failed sign-in event and map four fields:

1. Client application
2. Target resource
3. Applied Conditional Access policy
4. Failure stage

If Microsoft Edge appears as the application but another resource appears as the target, troubleshoot the resource dependency before changing the app protection policy.

For this incident, the decisive finding was not that Edge was blocked.

It was that Microsoft Edge Auth was the resource being blocked, and the tenant did not yet contain the service principal required to express the correct Conditional Access exclusion.

That is the difference between chasing a MAM symptom and correcting the actual identity control path.

Implementation checklist

• ☐ Confirm error 53003 in the Entra sign-in log.
• ☐ Record both Application ID and Resource ID.
• ☐ Verify the blocked resource is Microsoft Edge Auth.
• ☐ Query the tenant for service principal App ID f2d19332-a09d-48c8-a53b-c49ae5502dfc.
• ☐ Create it only if it does not exist.
• ☐ Use delegated Application.ReadWrite.All; avoid unnecessary directory-wide permission.
• ☐ Add Microsoft Edge Auth only to the required block-policy exclusion.
• ☐ Retest with a pilot user and clean Edge work-profile state.
• ☐ Confirm both successful sign-in and enforcement of the app protection policy.
• ☐ Document and periodically review the exclusion.

Official references

• Data Protection for Windows MAM
• Require an app protection policy on Windows devices
• Create servicePrincipal — Microsoft Graph v1.0
• Microsoft Edge and Conditional Access
• Block authentication flows with Conditional Access