CLI for Microsoft 365 MCP Server: Conditional Access Policy blocks browser login on Microsoft Corporate Tenant

[JohnMavic]

SUMMARY

The CLI for Microsoft 365 (v11.4.0) and its MCP Server cannot be used on Microsoft's own corporate tenant because the Conditional Access Policy blocks the browser-based authentication during "m365 setup" / "m365 login". This effectively makes the entire MCP ecosystem unusable for Microsoft employees who want to build AI agents that interact with their own M365 data.

ENVIRONMENT

CLI for Microsoft 365: v11.4.0
OS: Windows 11 (Microsoft Corporate Device)
Tenant: Microsoft Corporate (microsoft.com, Entra ID)
Node.js: v22.15.0
Auth method: Browser (default, configured via m365 setup)

STEPS TO REPRODUCE

1. Install CLI for Microsoft 365: npm install -g @pnp/cli-microsoft365
2. Run the interactive setup: m365 setup
3. Select: "Create a new app registration", "All scopes", "Interactively", Auth type: browser
4. Confirm settings. CLI opens browser for Microsoft login.
5. Result: Browser shows "Sorry, a security policy is preventing access" (Conditional Access Policy, error 53003)

The login never completes. No app registration is created. The CLI and MCP Server are completely non-functional.

EXPECTED BEHAVIOR

The CLI should either:

1. Support an authentication method that works within corporate Conditional Access constraints (e.g., device-based auth, WAM/broker, managed identity)
2. Clearly document which tenants/policies are incompatible and suggest alternatives
3. Allow using an existing, pre-approved app registration that has already been granted the necessary permissions by an admin

ACTUAL BEHAVIOR

The CLI's only interactive auth path (browser login) is blocked by Conditional Access. There is no fallback, no error handling, and no guidance on how to proceed. The setup wizard completes all configuration steps successfully, only to fail at the final authentication step with no recovery option.

WHY THIS MATTERS

Microsoft is actively promoting MCP (Model Context Protocol) as the standard for AI-to-service integration. The CLI for Microsoft 365 MCP Server is positioned as the official bridge between AI agents and M365 data (Outlook, Teams, SharePoint, etc.). However:

• Microsoft's own employees cannot use it on their corporate devices
• Any enterprise with strict Conditional Access policies will face the same blocker
• The only working alternative for M365 data access is Work IQ, which uses the Microsoft Search API with limited capabilities (e.g., cannot return Sent Items details, see microsoft/work-iq-mcp issue Blueprint inheritance not applied correctly #55)

This creates a paradox: Microsoft promotes MCP as the future of AI integration, but its own security infrastructure prevents it from working.

SUGGESTED SOLUTIONS

1. Support Windows Authentication Manager (WAM) / broker-based auth -- leverages existing device trust and SSO tokens, bypassing Conditional Access restrictions for compliant devices
2. Support certificate-based authentication for the MCP server context -- admins can pre-provision certificates for approved apps
3. Allow "m365 setup" to use an existing app registration with pre-granted admin consent, skipping the need for interactive app creation
4. Document enterprise deployment patterns -- how should an admin pre-configure the CLI for use in locked-down tenants?

RELATED ISSUES

Issue #287 in this repo -- App Registration created by A365 CLI is managed/locked, preventing permission changes (same ecosystem, different symptom)
microsoft/work-iq-mcp issue #55 -- Work IQ Sent Items limitation (the alternative that does work has its own gaps)

DISCLOSURE

I'm a Microsoft employee (FTE) testing this on our internal corporate tenant. Happy to collaborate with the product team internally -- reach out via Microsoft Teams.

Tested February 2026.

[github-actions]

[AUTO-TRIAGE] Team Assistant Triage

This issue has been automatically analyzed and triaged.

AI Decision Reasoning: Type: Classified as 'bug' because the issue describes a critical failure in the CLI's authentication flow, rendering the tool completely unusable in specific environments due to Conditional Access Policy restrictions.
Priority: Assigned P1 because the issue prevents Microsoft employees and potentially other enterprises with strict Conditional Access policies from using the CLI, which is positioned as a critical tool for AI-to-service integration within the MCP ecosystem. [Security issue detected: Security keywords detected: security]
Copilot: Security issues require human review and should not be auto-fixed
Assignment: Security issue assigned to security lead. Security keywords detected: security
Labels: Applied labels bug, P1, security based on issue type and priority

Labels and assignee have been applied based on this analysis.

[github-actions]

[AUTO-TRIAGE] Results

Classification: bug
Priority: P1
Confidence: 100.0%

Recommended Assignee: @sellakumaran

Analysis:
type rationale: Classified as 'bug' because the issue describes a critical failure in the CLI's authentication flow, rendering the tool completely unusable in specific environments due to Conditional Access Policy restrictions.

priority rationale: Assigned P1 because the issue prevents Microsoft employees and potentially other enterprises with strict Conditional Access policies from using the CLI, which is positioned as a critical tool for AI-to-service integration within the MCP ecosystem. [Security issue detected: Security keywords detected: security]

copilot rationale: Security issues require human review and should not be auto-fixed

assignment rationale: Security issue assigned to security lead. Security keywords detected: security

labels rationale: Applied labels bug, P1, security based on issue type and priority

[SUGGESTION] Suggested Approach

1. Implement support for device-based authentication or WAM/broker authentication in the CLI. Start by adding a new authentication flow in src/Microsoft.Agents.A365.DevTools.Cli/Auth that leverages the Microsoft Authentication Library (MSAL) for .NET. This can bypass Conditional Access Policy restrictions by using device-bound credentials.
2. Introduce an option in the m365 setup command to use an existing app registration. Modify the setup wizard logic in src/Microsoft.Agents.A365.DevTools.Cli/SetupWizard.cs to allow users to input the client ID and tenant ID of a pre-approved app registration, skipping the browser-based flow entirely.
3. Add detailed error handling and fallback mechanisms in the authentication module (likely in src/Microsoft.Agents.A365.DevTools.Cli/Auth). When a Conditional Access Policy error (e.g., error 53003) is detected, provide actionable guidance in the CLI output, such as suggesting alternative authentication methods or pre-approved app registrations.
4. Update the documentation in docs/authentication.md to clearly outline the limitations of browser-based authentication under Conditional Access Policies. Include step-by-step instructions for setting up device-based authentication or using pre-approved app registrations as alternatives.
5. Add automated tests in src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/AuthTests to validate the new authentication methods and ensure compatibility with Conditional Access constraints. Include test cases for error handling scenarios such as blocked browser login attempts.

---

Generated by TeamAssistant Auto-Triage powered by GitHub Models

[github-actions]

SLA Escalation Alert

This P1 issue has exceeded its SLA threshold.

Metric	Value
Priority	P1
SLA Threshold	48 hours
Time Since Update	68.5 hours
Current Assignees	@sellakumaran

Action: This issue is already assigned to a Tech Lead but remains unresolved.

Escalating to Engineering Manager @ajmfehr for visibility.

Tech Leads: @sellakumaran

---

Generated by AutoTriage SLA Escalation

[github-actions]

SLA Escalation Alert

This P1 issue has exceeded its SLA threshold.

Metric	Value
Priority	P1
SLA Threshold	48 hours
Time Since Update	48.1 hours
Current Assignees	@sellakumaran

Action: This issue is already assigned to a Tech Lead but remains unresolved.

Escalating to Engineering Manager @ajmfehr for visibility.

Tech Leads: @sellakumaran

---

Generated by AutoTriage SLA Escalation