Enterprise implementation of Microsoft Defender for Cloud Apps integrated with Microsoft Defender for Endpoint — delivering Shadow IT detection, cloud application governance, OAuth monitoring, and SaaS security posture management.
Overview · Architecture · Implementation · Scripts · Gallery
This project documents the end-to-end integration of Microsoft Defender for Cloud Apps (MDCA) with Microsoft Defender for Endpoint (MDE) — the cornerstone of the Applications pillar of the Microsoft Zero Trust security model.
The integration uses the MDE agent already deployed on managed endpoints as a passive signal source, forwarding all cloud traffic metadata to MDCA's Cloud Discovery engine. This eliminates the need for network appliances, proxy configurations, or log collectors for managed-device coverage — achieving full cloud application visibility the moment the integration toggle is enabled.
The implementation covers four sequential phases: enabling the MDE integration, connecting the Microsoft 365 API connector, validating data flow via the Governance Log, and configuring OAuth application monitoring.
| Metric | Value |
|---|---|
| Implementation Phases | 4 |
| Screenshots / Evidence | 4 |
| PowerShell Scripts | 4 |
| Additional Infrastructure Required | None |
| Cloud App Catalogue Coverage | 31,000+ apps |
| Deployment Pattern | Portal GUI → Validate → Monitor |
Modern enterprises face an uncontrolled SaaS sprawl problem:
- Shadow IT is pervasive. Employees use an average of 10–20× more cloud applications than IT has approved. File sharing via personal Dropbox, collaboration in unauthorised Slack workspaces, or AI-powered tools with undefined data retention policies — all create unmanaged data exfiltration paths.
- OAuth consent grant attacks are rising. Attackers register malicious OAuth apps and phish users into granting them read/write access to Microsoft 365 data. Without visibility into OAuth app permissions, security teams cannot detect these compromises.
- Legacy proxy visibility is insufficient. Traditional SaaS visibility based on web proxy logs only covers browser traffic and lacks the context to identify the application, the user, and the data risk level.
- Compliance requires SaaS governance. ISO 27001, SOC 2, GDPR, and CMMC require demonstrable control over third-party data access — a standard that cannot be met without application-level visibility and governance.
Without MDCA integrated into the endpoint, the security team is operating with a fundamental blind spot: they can see on-premises activity but not cloud application behaviour — where most modern work actually happens.
Microsoft Defender for Cloud Apps acts as a Cloud Access Security Broker (CASB) — sitting between users and cloud applications to provide visibility, compliance, and data protection. Integrated with MDE, it operates without network-layer interception:
Managed Endpoint (MDE Agent)
│
│ Cloud traffic metadata
│ (app name, URL, bytes, user, timestamp)
▼
Microsoft Defender for Endpoint (Signal Aggregation)
│
│ MDCA Integration Toggle = ON
│
▼
Microsoft Defender for Cloud Apps
│
├── Cloud Discovery Dashboard
│ └── 31,000+ app catalogue → Risk scores → Shadow IT report
│
├── Microsoft 365 App Connector (API)
│ └── Exchange · SharePoint · Teams · OneDrive activity
│
├── OAuth App Monitoring
│ └── Consent grants · Permission levels · Publisher verification
│
└── App Governance
└── Automated policies · Alerts · Remediation actions
Key design decisions:
- MDE agent used as the discovery source — no proxy required for managed devices
- Microsoft 365 API connector for deep activity-level visibility beyond network metadata
- OAuth monitoring enabled from day one — consent grant attacks detected immediately
- Governance Log validated before any enforcement policies are created
graph TB
subgraph Endpoints["💻 Managed Endpoints (MDE Enrolled)"]
W[Windows Devices]
M[macOS Devices]
L[Linux Devices]
end
subgraph MDE["🛡️ Microsoft Defender for Endpoint"]
SENSOR[MDE Sensor\nKernel-level traffic metadata]
ADV[Advanced Features\nMDCA Integration: ON]
SENSOR --> ADV
end
subgraph MDCA["☁️ Microsoft Defender for Cloud Apps"]
CD[Cloud Discovery\n31,000+ App Catalogue]
AC[App Connectors\nMicrosoft 365 API]
OA[OAuth App Monitor\nConsent Grant Visibility]
AG[App Governance\nAutomated Policies]
GL[Governance Log\nAudit Trail]
ACT[Activity Log\nUser Behaviour]
end
subgraph M365["📦 Microsoft 365 Services"]
EXO[Exchange Online]
SPO[SharePoint Online]
TEA[Microsoft Teams]
ODB[OneDrive for Business]
end
subgraph EntraID["🪪 Microsoft Entra ID"]
CA_CTRL[Conditional Access\nApp Control]
OAUTH[OAuth App Registry\nConsent Grants]
end
subgraph XDR["⚡ Microsoft Defender XDR"]
INC[Incident Queue]
HUNT[Advanced Hunting]
ALERT[Alert Correlation]
end
W --> SENSOR
M --> SENSOR
L --> SENSOR
ADV -->|Cloud traffic metadata| CD
ADV -->|Signal sharing| MDCA
M365 -->|API Connector| AC
EXO --> M365
SPO --> M365
TEA --> M365
ODB --> M365
EntraID -->|User identity context| MDCA
OAUTH -->|Consent grant data| OA
CD --> GL
AC --> GL
OA --> GL
AG --> GL
ACT --> GL
GL --> XDR
ALERT --> INC
HUNT --> MDCA
style MDE fill:#0078D4,color:#fff
style MDCA fill:#00B7C3,color:#fff
style XDR fill:#FFB900,color:#1B1B1B
style EntraID fill:#7719AA,color:#fff
style M365 fill:#D83B01,color:#fff
sequenceDiagram
participant EP as 💻 Endpoint (MDE)
participant MDE as 🛡️ MDE Portal
participant MDCA as ☁️ MDCA
participant LOG as 📋 Governance Log
EP->>MDE: Cloud app traffic metadata
Note over MDE: Advanced Features:\nMDCA Integration = ON
MDE->>MDCA: Forward discovery data stream
MDCA->>MDCA: Score against 31,000+ app catalogue
MDCA->>MDCA: Map to users via Entra ID identity
MDCA->>LOG: Log discovery events
MDCA-->>MDE: Return threat intelligence\n(risky app alerts → MDE incidents)
Note over EP,LOG: Bidirectional: discovery goes up, threat intel comes back
flowchart LR
subgraph Detection["🔍 Detection"]
U[User Grants Consent\nto Third-Party App]
E[Entra ID Records\nOAuth Grant]
M[MDCA Detects\nNew OAuth App]
end
subgraph Assessment["📊 Assessment"]
PERM[Evaluate Permission Level\nRead / Write / Full Access]
PUB[Check Publisher\nVerified / Unverified]
COMM[Check Community Use\nWidely used? First seen?]
RISK[Calculate Risk Score]
end
subgraph Action["⚙️ Governance Action"]
LOW[Low Risk\nApprove & Monitor]
MED[Medium Risk\nAlert Security Team]
HIGH[High Risk\nAuto-disable + Notify User]
end
U --> E --> M
M --> PERM & PUB & COMM
PERM & PUB & COMM --> RISK
RISK -->|Risk < 3| LOW
RISK -->|Risk 3–6| MED
RISK -->|Risk > 6| HIGH
| Component | Details |
|---|---|
| Tenant Type | Microsoft 365 E5 Developer Tenant |
| Identity Provider | Microsoft Entra ID |
| Licensing Required | Microsoft 365 E5 or Microsoft Defender for Cloud Apps Plan 1/2 |
| MDE Portal | security.microsoft.com |
| MDCA Portal | security.microsoft.com/cloudapps |
| API Reference | Microsoft Graph Security API + MDCA REST API |
| Admin Role Required | Security Administrator or Global Administrator |
| Technology | Role in This Implementation |
|---|---|
| Microsoft Defender for Cloud Apps | CASB — cloud visibility, governance, and DLP |
| Microsoft Defender for Endpoint | Signal source — cloud traffic metadata from enrolled endpoints |
| Microsoft 365 App Connector | API-level activity monitoring for Exchange, SharePoint, Teams, OneDrive |
| App Governance | Automated OAuth app policy engine |
| OAuth App Monitoring | Consent grant visibility and risk assessment |
| Microsoft Entra ID | User identity context and Conditional Access App Control |
| Microsoft Defender XDR | Unified portal and incident correlation |
| Microsoft Graph Security API | PowerShell automation for MDCA reporting |
| Governance Log | Audit trail for all MDCA policy actions |
Licensing
- Microsoft 365 E5, Microsoft Defender for Cloud Apps Plan 1 or Plan 2, or Microsoft 365 E3 + Defender for Cloud Apps add-on
- Microsoft Defender for Endpoint Plan 2 (included in M365 E5)
Roles Required
- Global Administrator or Security Administrator (for initial integration toggle)
- Cloud App Security Administrator (for ongoing MDCA management)
Pre-Implementation Checks
- At least one device enrolled in Microsoft Defender for Endpoint
- Microsoft 365 services (Exchange Online, SharePoint, Teams) active in the tenant
- Entra ID audit logging enabled
- Confirm no existing third-party CASB solution that may conflict with MDCA
PowerShell Prerequisites
# Install Microsoft Graph PowerShell SDK
Install-Module Microsoft.Graph -Scope CurrentUser -Force
# Verify
Get-Module Microsoft.Graph -ListAvailable | Select-Object Name, VersionDeployment Safety Pattern: Each phase was validated before proceeding. Cloud Discovery data was reviewed in read-only mode before any blocking or governance policies were created — preventing disruption to business-critical SaaS workflows.
Objective: Activate the MDE → MDCA signal channel so that cloud traffic metadata from all enrolled endpoints flows into the MDCA Cloud Discovery engine.
Why this matters: This single toggle transforms every MDE-enrolled endpoint into a passive cloud application discovery sensor. Without it, MDCA has no visibility into applications accessed by managed devices — the most critical cohort for enterprise SaaS governance.
Navigation: Microsoft Defender XDR → Settings → Endpoints → Advanced Features
- Sign in to security.microsoft.com with a Security Administrator or Global Administrator account.
- Navigate to Settings → Endpoints → Advanced Features.
- Scroll to Microsoft Defender for Cloud Apps.
- Toggle to On.
- Click Save preferences.
What this shows: The Microsoft Defender for Cloud Apps toggle in the MDE Advanced Features settings blade, set to On. Once saved, the MDE agent on every enrolled endpoint begins forwarding cloud application traffic metadata (destination app, URL, bytes transferred, user identity, timestamp) to the MDCA Cloud Discovery engine. This is visible within 15–30 minutes for actively-used devices.
Best practice: This toggle is a tenant-wide setting — it applies to all MDE-enrolled devices simultaneously. There is no per-device or per-group scoping at this layer. Ensure all device owners are informed that cloud app usage will now be monitored before enabling this in a production environment.
Validation:
# Verify the integration is active via Graph API
Connect-MgGraph -Scopes "SecurityEvents.Read.All"
# Navigate to MDCA → Cloud Discovery → Dashboard
# Confirm endpoint traffic data appears within 30 minutesObjective: Establish a direct API connection between MDCA and Microsoft 365 services to enable deep activity-level monitoring beyond network traffic metadata.
Why this matters: The MDE integration provides network-layer visibility (what app was accessed, by whom, how much data). The Microsoft 365 App Connector provides application-layer visibility — the actual actions taken inside Microsoft 365 apps: what files were downloaded, what emails were sent to external recipients, who accessed a SharePoint site, what Teams messages contained sensitive keywords.
Navigation: Microsoft Defender XDR → Cloud Apps → Settings → Connected Apps → App Connectors
- Navigate to Cloud Apps → Settings → Connected Apps → App Connectors.
- Click Connect an app → Select Microsoft 365.
- Authenticate with a Global Administrator account (required for API permissions consent).
- Grant the required permissions when prompted.
- Confirm the connector shows Connected status with a recent sync timestamp.
What this shows: The Microsoft 365 App Connector active in the MDCA Connected Apps blade. The connector status is Connected, indicating MDCA has successfully authenticated and is actively ingesting activity data from Exchange Online, SharePoint Online, Microsoft Teams, and OneDrive for Business via their respective Graph API endpoints.
Coverage provided by the Microsoft 365 connector:
| Service | Activity Data Ingested |
|---|---|
| Exchange Online | Mail flow, external forwarding rules, suspicious inbox rules, mail send volume |
| SharePoint Online | File access, download activity, external sharing events, permission changes |
| Microsoft Teams | Message activity, external channel access, file sharing in channels |
| OneDrive for Business | File sync, download volume, sharing to external users |
Best practice: The account used to authorise the Microsoft 365 connector must remain active and licenced. If this account is deleted or its licence removed, the connector silently stops syncing. Document the connector owner account and include it in your offboarding checklist.
Objective: Confirm end-to-end data flow by reviewing the MDCA Governance Log for successful synchronisation events from the Microsoft 365 connector.
Why this matters: The Governance Log is the single source of truth for all MDCA-driven actions and connector activity. Verifying successful entries here confirms that the connector is working, data is flowing, and MDCA has the activity context it needs to enforce policies. A silent connector failure (no events appearing) is only detectable here.
Navigation: Microsoft Defender XDR → Cloud Apps → Policies → Governance Log
- Navigate to Cloud Apps → Policies → Governance Log.
- Filter by App = Microsoft 365 (or Exchange, SharePoint, Teams individually).
- Confirm entries appear with Status = Success.
- Verify timestamps align with expected activity periods.
- Check that Action types correspond to the expected connector sync events.
What this shows: The MDCA Governance Log populated with sync and activity events from the Microsoft 365 App Connector. Each row represents a governance action or data ingestion event with its status, the affected object, the triggering policy or action type, and the timestamp. Successful entries here confirm the complete data pipeline from Microsoft 365 → MDCA is operational.
Governance Log entry anatomy:
| Column | Description |
|---|---|
| Date | UTC timestamp of the action |
| App | The connected application (Exchange, SharePoint, Teams) |
| Object | The target — user, file, policy, or activity |
| Action | What MDCA did — alert, quarantine, notify, sync |
| Status | Success / Failed / Pending |
| Initiated by | System (automated policy) or admin (manual action) |
Best practice: Bookmark the Governance Log and review it weekly during the initial post-deployment period. Any Failed status entries indicate a connector issue, a permission problem, or a policy misconfiguration that requires immediate investigation.
Objective: Review all third-party OAuth applications that have been granted access to Microsoft 365 tenant data, assess their risk, and establish monitoring policies.
Why this matters: OAuth consent grant attacks are one of the most dangerous and underrated attack vectors in Microsoft 365 environments. Attackers register malicious OAuth apps, craft a phishing email with a consent URL, and — if a user clicks through — the app gains persistent read/write access to the user's mailbox, files, and contacts. Unlike password-based attacks, these permissions survive password resets and MFA changes.
Navigation: Microsoft Defender XDR → Cloud Apps → Investigate → OAuth Apps
- Navigate to Cloud Apps → Investigate → OAuth Apps.
- Review the full list of OAuth apps with M365 permissions.
- For each app, evaluate:
- Permission level — Read vs. Write vs. Full Access
- Community use — How many tenants globally use this app?
- Publisher — Is the publisher verified by Microsoft?
- User scope — How many users in your tenant have granted consent?
- Filter for High permission apps with Low community use — these are the highest-risk candidates.
- Create an OAuth App policy to automatically alert on new apps matching a risk threshold.
What this shows: The MDCA OAuth Apps monitoring blade displaying the full inventory of third-party applications that have been granted OAuth 2.0 permissions to access Microsoft 365 tenant data. Each app entry shows the permission level (Read, Write, Full Access), community use score, publisher verification status, and the number of tenant users who have granted consent. This view enables the security team to identify risky, unknown, or overly-permissive apps and take immediate governance action.
Risk indicators to investigate immediately:
| Indicator | Risk | Action |
|---|---|---|
| Full Access permission | Critical | Review app purpose; ban if not business-justified |
| Unverified publisher | High | Contact publisher or ban if unknown |
| Low community use (<10 tenants) | High | Treat as potentially malicious unless confirmed |
| High volume of users (>50%) | Medium | Ensure app is known and business-approved |
| Recently granted (last 7 days) | Medium | Cross-reference with any phishing reports |
Governance action:
MDCA → Cloud Apps → Investigate → OAuth Apps
→ Select app → [Ban] or [Revoke] user consent tokens
Banning an app revokes all existing consent tokens and prevents future authorisation — blocking the app's access to all M365 data immediately.
All scripts use the Microsoft Graph Security API or the MDCA REST API. The Microsoft.Graph module v2.x is required throughout.
| Script | Purpose |
|---|---|
Get-MDCADiscoveredApps.ps1 |
Export Cloud Discovery app inventory with risk scores |
Get-OAuthApps.ps1 |
Report all OAuth apps with permissions and risk indicators |
Export-MDCAGovernanceLog.ps1 |
Export Governance Log entries to CSV for audit |
Set-AppSanctionStatus.ps1 |
Sanction or unsanction cloud apps by app ID |
- Advanced Features → Microsoft Defender for Cloud Apps toggle set to On
- Settings saved successfully
- Cloud Discovery data appears in MDCA within 30 minutes of toggle activation
- Endpoint-sourced apps visible in Cloud Discovery dashboard
- App connector created and authenticated with Global Administrator
- Connector status shows Connected
- Sync timestamp is recent (within the expected interval)
- Exchange, SharePoint, Teams, OneDrive all covered under connector scope
- Governance Log entries present for Microsoft 365 connector
- Entry status = Success (not Failed or Pending)
- Action types align with expected sync and activity events
- No error entries indicating permission or connectivity problems
- OAuth Apps blade populated with tenant app inventory
- Each app shows permission level, community use, and publisher verification
- High-risk apps (high permission + low community use) reviewed and documented
- OAuth App policy created to alert on new high-risk consent grants
Discovering Shadow IT is only the first step. A governance framework must follow:
- Categorise — Review discovered apps and assign Sanctioned, Monitored, or Blocked status
- Communicate — Inform users of unsanctioned app policy before blocking (preventing support escalations)
- Block — Create a Conditional Access policy or MDCA blocking policy for Blocked-tagged apps
- Review — Quarterly review of the Cloud Discovery dashboard for newly-discovered apps
| Risk | Mitigation |
|---|---|
| Illicit consent grant attack | Enable user consent restriction in Entra ID → require admin approval for all OAuth consent |
| Over-privileged existing apps | Audit OAuth apps monthly via Get-OAuthApps.ps1; revoke unnecessary permissions |
| Unverified publisher apps | Configure MDCA policy: alert on any new OAuth app with unverified publisher |
| App consent by non-admins | Entra ID → Enterprise apps → Consent and permissions → Block user consent (admin consent only) |
MDCA stores activity log data for 90 days by default. For compliance scenarios requiring longer retention:
- Forward MDCA alerts to Microsoft Sentinel via the MDCA data connector
- Sentinel retains data per the configured Log Analytics workspace retention policy (up to 2 years in hot tier)
The MDCA + Entra ID integration enables Conditional Access App Control — session-level proxy control for SaaS apps. This requires:
- Entra ID Conditional Access policy routing traffic through MDCA proxy
- Supported apps: Azure Portal, Salesforce, ServiceNow, Workday, Box, and 100+ others via reverse proxy
1. The MDE integration toggle is instant; the data takes time
The toggle saves immediately, but Cloud Discovery data takes 15–30 minutes to appear for active devices. Waiting for data before declaring the integration "working" is essential — premature troubleshooting wastes time.
2. The Microsoft 365 connector requires a persistent, licenced admin account
The account used to authenticate the connector must remain active. This is the single most common cause of connector sync failures post-deployment. Use a dedicated service account, not a personal admin account.
3. Review OAuth apps before creating policies
The initial OAuth app inventory in any tenant will reveal surprises — apps consented years ago by former employees, consumer apps used for personal productivity, and sometimes genuinely suspicious apps. Understand the landscape before creating auto-disable policies.
4. Start with Alert, not Block, for app governance
App Governance policies with Auto-disable actions can break legitimate business applications. Always start with Alert mode for 30 days before escalating to enforcement actions. The first 30 days of alerts will surface your known-good apps.
5. Block user OAuth consent in Entra ID immediately
One of the highest-value, lowest-disruption controls: navigate to Entra ID → Enterprise applications → Consent and permissions → set "Users can consent to apps accessing company data on their behalf" to No. This prevents new illicit consent grant attacks while MDCA monitors existing grants.
6. Shadow IT discovery reveals the true SaaS footprint
In this lab environment, Cloud Discovery surfaced applications that were entirely unknown to IT. In production environments this is even more pronounced — the discovered app count is routinely 5–20× higher than the approved app list.
| Outcome | Impact |
|---|---|
| Full cloud app visibility | Every app accessed by a managed endpoint is now visible, risk-scored, and auditable |
| Shadow IT eliminated as a blind spot | Security team can see, govern, and block unapproved cloud applications |
| OAuth attack surface reduced | All third-party app permissions inventoried; high-risk apps identified and actionable |
| Zero additional infrastructure | MDE agent already deployed — MDCA integration costs no new hardware or network changes |
| Compliance posture improved | Demonstrable SaaS governance satisfies ISO 27001 A.12, SOC 2 CC6.6, and GDPR Art. 32 |
| Unified security operations | MDCA alerts surface in Defender XDR incident queue alongside endpoint and identity alerts |
- Conditional Access App Control — Deploy MDCA session proxy for sanctioned SaaS apps (block downloads, prevent copy-paste, watermark content)
- Session Policies — Real-time content inspection for data uploaded to cloud storage apps
- File Policies — Scan Microsoft 365 content for sensitive data types (PII, financial data) and auto-quarantine
- Cloud Discovery Log Collectors — On-premises log collectors for firewall/proxy logs covering non-MDE devices
- Microsoft Sentinel Integration — Connect MDCA as a Sentinel data source for long-term retention and custom analytics
- Power Automate MDCA Playbooks — Automated response workflows triggered by MDCA high-risk app alerts
- Restrict User OAuth Consent — Enforce admin-approval-only for OAuth consent in Entra ID
- SSPM (SaaS Security Posture Management) — Review security configuration recommendations for connected SaaS apps
| Screenshot | Phase | Description |
|---|---|---|
|
Phase 1 | MDCA Integration toggle enabled in MDE Advanced Features |
|
Phase 2 | Microsoft 365 App Connector — Connected status |
|
Phase 3 | Governance Log — successful sync validation |
|
Phase 4 | OAuth Applications — consent grant inventory |
| Resource | Link |
|---|---|
| MDCA Overview | learn.microsoft.com/defender-cloud-apps |
| MDE + MDCA Integration | learn.microsoft.com — MDE Integration |
| Microsoft 365 App Connector | learn.microsoft.com — M365 Connector |
| OAuth App Governance | learn.microsoft.com — App Governance |
| Cloud Discovery Overview | learn.microsoft.com — Cloud Discovery |
| OAuth Consent Grant Investigation | learn.microsoft.com — Consent Grant |
| Block Legacy Authentication | learn.microsoft.com — Block Legacy Auth |
| Microsoft Zero Trust | learn.microsoft.com/security/zero-trust |
| Microsoft Graph Security API | learn.microsoft.com/graph/security-api-overview |
microsoft-defender-cloud-apps mdca microsoft-defender-endpoint shadow-it cloud-discovery oauth-security app-governance casb microsoft-365 saas-security zero-trust cloud-security graph-api powershell
Lokesh M
Senior Infrastructure Engineer
Part of the Microsoft 365 Infrastructure Portfolio — a series of enterprise-grade implementation projects demonstrating Zero Trust security architecture across Identity, Endpoint, Email, and Cloud Applications.
Project 1 — Identity · Project 2 — Endpoint · Project 3 — Email Security · Project 4 — Vulnerability Management · Project 5 — SIEM · Project 6 — Identity Protection · Project 7 — Cloud Apps