SOC Anywhere SOC Anywhere
Product Pricing FAQ Contact Blog Login

SOC Anywhere vs Custom Microsoft Defender Integrations

June 7, 2026 · 17 min read

Microsoft Defender for Endpoint exposes a rich set of REST APIs through Microsoft Graph. Those APIs make it technically possible to build almost any notification or response workflow you can design: pull incident data on a schedule, route severity-five alerts to Pushover, post cards to a Teams channel, create a custom analyst portal in Power Apps, or build a fully custom mobile application.

The question is not whether a custom Microsoft Defender integration can work. The question is how much of the complete workflow your team wants to build, test, secure and maintain alongside everything else it already runs.

This article compares the main approaches: Azure Functions, Logic Apps, Power Automate, Power Apps, Teams or Slack, email, Pushover and a fully custom mobile application. It explains the technical work each option requires, where SOC Anywhere fits and where it does not, and how to decide which path is right for your team.

Quick comparison

The table below gives a starting point. The detail for each option follows in later sections.

Option Setup effort Mobile push Defender context Write-back to Defender Ongoing maintenance
Built-in email Low No Limited No None
Teams or Slack Low to medium Via mobile app Limited No Low to medium
Pushover Medium Yes Custom message only No Low to medium
Logic Apps Medium Via third-party connector Partial, custom expressions With extra steps Medium
Power Automate Medium Via Power Automate app Partial, custom expressions With extra steps Medium
Azure Functions High Via third-party service Custom, you build it Yes, you build it High
Power Apps High Via Power Apps app Custom, you build it Yes, you build it High
Fully custom mobile app Very high Yes, you build it Custom, you build it Yes, you build it Very high
SOC Anywhere Low (one-time app registration) Yes, native iOS and Android Full Defender-native context Yes, managed None (managed service)

What a custom Defender integration needs to do

Before comparing the options, it helps to enumerate everything a complete integration actually requires. Most teams underestimate the scope when they start.

Microsoft Graph Security API endpoints

The Defender XDR incidents API is available at https://graph.microsoft.com/v1.0/security/incidents. Alerts are available at https://graph.microsoft.com/v1.0/security/alerts_v2. Both require an Entra ID app registration with appropriate permissions. Reading incidents requires SecurityIncident.Read.All. Writing status, classification, assignment, tags and comments back to Defender requires SecurityIncident.ReadWrite.All. Reading alerts requires SecurityAlert.Read.All. The Microsoft Graph incidents API reference and alerts_v2 reference document current endpoints and permissions.

Authentication

Every call to Microsoft Graph requires a valid access token. Background services use an OAuth 2.0 client credentials flow with a client secret or a certificate. Client secrets expire and must be rotated before they do. Certificates need renewal. Both need an owner who monitors expiry and a secure location for the credential. A token cache prevents re-authenticating on every call; that cache needs to exist somewhere in your infrastructure.

Retrieval and state

Scheduled polling calls the incidents endpoint periodically and decides what is new or changed. The Graph API supports $top, $skip, $filter and $orderby query parameters. Without stored state, your integration either sends a duplicate notification every cycle or misses incidents entirely. State must live somewhere: a database, a storage account, a cache. That store needs backup, recovery and migration planning.

Pagination

A real Defender tenant with hundreds of incidents will not return all results in a single API call. Your integration must follow pagination using $skip or @odata.nextLink depending on the endpoint version, and handle the case where new incidents arrive between page requests. Missed pagination means missed incidents.

Filtering

Not every Defender incident warrants a push notification. Severity filters, classification filters, status filters and device group scoping are all logic your team writes, tests and updates when requirements change.

Notification delivery

Your integration retrieves incidents and decides what to send, but delivery to a mobile device requires a separate service. Pushover, Firebase Cloud Messaging, Apple Push Notification Service, a Teams webhook or an SMTP relay each have their own APIs, credentials and failure modes. Delivery is a distinct problem from retrieval.

Write-back

If analysts acknowledge, classify or comment on an incident through your custom tool, those changes need to flow back to Defender through the Graph incidents PATCH endpoint. Without write-back, Defender and your tool drift out of sync, and the official incident record becomes unreliable.

Throttling and retries

Microsoft Graph throttles requests when request rate exceeds defined limits. The Graph throttling documentation describes the behavior; throttled calls return HTTP 429 with a Retry-After header. Without retry logic and backoff, silent failures accumulate during busy periods.

Monitoring the integration itself

The integration pipeline needs monitoring independent of Defender. A failed Logic App run, an unhandled exception in a function, an expired Pushover token or a polling job that stops running will all silently halt your notifications. You need alerting on the integration health, not just the Defender incidents it processes. Missed Microsoft Defender Alerts? Here Is Why It Happens and How to Fix It covers why notification failures are often discovered only after a real incident has already been missed.

Custom integration options

Azure Logic Apps

Azure Logic Apps is a low-code orchestration service. You build a Defender incident polling workflow visually using an HTTP connector to call Graph, a Recurrence trigger to schedule polling, and output connectors to route results to email, Teams, SMS or Pushover. A step-by-step guide to this approach using Logic Apps to post Defender alerts to Teams is available in How to Receive Defender for Endpoint Notifications in Microsoft Teams.

Advantages: visual designer, built-in run history and retry, extensive connector library, no server infrastructure to manage, accessible to non-developers.

Limitations: Logic Apps does not natively understand Defender incident structure. You write expressions or Compose actions to extract severity, title, alert categories and evidence fields. State for deduplication needs an external store such as Azure Table Storage, Cosmos DB or SQL. The Microsoft Graph Security connector for Logic Apps is deprecated; check the current connector status in the Microsoft connector reference before designing a flow that depends on it. Complex runs accumulate technical debt and become harder to debug. The Logic App and its managed identity or service principal need an owner.

When it is a good choice: you need Defender alerts routed to an existing system, you have someone willing to maintain the flow and monitor its health, and the use case fits within Logic Apps' connector and expression capabilities.

Power Automate

Power Automate offers a similar visual flow-building approach and is more accessible to business users within Microsoft 365. Flows can post to Teams channels, send mobile push notifications through the Power Automate mobile app, or call HTTP endpoints.

Advantages: included in many Microsoft 365 licenses, deep Teams and Outlook integration, accessible to non-developers, mobile app with basic push support.

Limitations: calling Microsoft Graph directly requires the HTTP action or a custom connector, which may require premium licensing. The Microsoft Graph Security connector in Power Automate is deprecated; the Microsoft connector reference documents current status. Flows owned by individual users create handover risk when that person leaves. Complex security automation can push against Power Automate's intended governance scope.

When it is a good choice: you need simple alert routing into existing Microsoft 365 workflows, your team prefers visual tools over code, and the use case is straightforward enough to stay within standard connector capabilities.

Azure Functions

Azure Functions is the most flexible option. You write code in C#, Python, JavaScript or another supported language that polls Graph on a timer trigger, processes incidents with full custom logic, writes state to storage, delivers notifications through any channel you choose, and writes back to Defender.

Advantages: complete control over logic, authentication, state, filtering, delivery and write-back; source-controllable and testable; low Azure consumption costs at typical Defender polling volumes.

Limitations: you own everything. App registration, token management, secret rotation, state design, pagination logic, deduplication, throttle handling, retry logic, test coverage, deployment pipeline, monitoring, failure alerting and every future Graph API change. An Azure Function for Defender notifications is permanent infrastructure with a full operational lifecycle. It needs an on-call owner.

When it is a good choice: you have developer capacity, you need custom logic that no SaaS tool supports, and you are prepared to treat this as an ongoing engineering responsibility.

Power Apps

Power Apps lets you build a custom browser and mobile interface on top of Microsoft data sources and connectors.

Advantages: visual app builder, works in browser and on mobile, Dataverse integration, accessible to citizen developers.

Limitations: Power Apps provides a UI layer, not a backend. You still need a backend service to poll or subscribe to Defender incidents, normalize the data, and write changes back. A Defender-specific mobile app built on Power Apps requires Power Apps premium licensing, a backend service, Dataverse or another synchronized data store, secure credential management and an ongoing governance and release process.

When it is a good choice: you already have a backend Defender sync service, you need a custom interface beyond what existing tools offer, and you have the Power Apps licensing and citizen developer capacity to build and maintain the app.

Pushover

Pushover is a reliable mobile push delivery service with iOS, Android and desktop apps. It accepts HTTP POST requests with a message payload and delivers to registered devices. Some teams use it as the notification delivery layer behind a Defender polling script or Logic App.

Advantages: simple Pushover API, reliable delivery, low cost, good mobile apps, emergency-priority messages with acknowledgement support.

Limitations: Pushover delivers messages. It does not retrieve, parse or understand Defender incidents. You still need to build the retrieval, filtering and state management layer that feeds it. Pushover emergency-priority acknowledgement confirms that the notification was received and opened in the Pushover app; it does not acknowledge, update or close the incident in Microsoft Defender. Your Defender incident record is unaffected by any interaction with the Pushover notification.

When it is a good choice: you already have a Defender polling service and want a simple, reliable mobile delivery channel. Pushover is a strong delivery option; it is not a Defender integration by itself.

Teams or Slack

Posting Defender incidents to a Teams channel or Slack workspace is the most common first approach. A Logic App, Power Automate flow or incoming webhook posts a formatted card when new incidents appear.

Advantages: uses tools the team already has, no new mobile app required, low setup effort, familiar to the team.

Limitations: security alerts in a shared chat channel compete with operational messages, meeting notifications and general conversation. Reading or reacting to a Teams or Slack message does not acknowledge or update the incident in Microsoft Defender. There is no triage workflow, assignment tracking or Defender write-back built into a chat notification. Why Teams and Slack Fail for Security Alerts covers this pattern in detail.

When it is a good choice: low-severity awareness notifications in a dedicated security channel that the team actively monitors with discipline, supplementing a primary incident management workflow rather than replacing it.

Built-in Defender email notifications

Microsoft Defender for Endpoint includes built-in email notification rules. You configure which severity levels, alert categories and device groups trigger notifications, and Defender sends email to specified recipients. Configure Defender for Endpoint Email Notifications covers the setup process in detail.

Advantages: no custom code, no Azure services, no ongoing maintenance.

Limitations: email for security incident response has well-documented operational problems. Why Email-Based Defender Alerting Fails covers the core issues: no acknowledgement model, no ownership, no escalation chain, late delivery during busy periods and no mobile-optimized triage workflow. Email tells someone an incident exists; it does not help them investigate or act on it quickly.

When it is a good choice: as a backup channel or secondary notification path alongside a primary incident notification method, not as the primary response mechanism.

Fully custom mobile application

Some teams consider building their own native iOS and Android application that authenticates to Microsoft Graph, retrieves Defender incidents, presents them in a custom UI and allows triage actions.

Advantages: complete control over UX, push delivery, data model and branding.

Limitations: a production mobile application requires iOS and Android development, App Store and Play Store accounts and review cycles, push notification infrastructure (APNs and FCM), an appropriate OAuth 2.0 authentication flow (PKCE or similar), a backend API for Graph authentication and state management, a security review before distribution, and ongoing maintenance for OS updates, dependency patches and Graph API changes. This is a substantial and permanent engineering commitment.

When it is a good choice: almost never for internal tooling, unless you are a software company building Defender tooling as a product.

Polling versus change notifications

Two architectural patterns exist for retrieving Defender incidents from Microsoft Graph.

Scheduled polling

Your service calls the incidents endpoint on a schedule, tracks a watermark (a timestamp or the last processed incident identifier), retrieves incidents updated since that watermark, processes them and advances the watermark. This approach is straightforward to implement and reason about. The tradeoff is latency equal to the polling interval and continuous Graph API traffic regardless of incident volume.

Change notifications

Microsoft Graph supports change notifications (webhooks) for some resources, which allow Graph to push a notification to your endpoint when a supported resource changes. The Graph change notifications documentation describes supported resources, subscription limits, payload format and the validation handshake your endpoint must complete.

Check current documentation to confirm which specific security resources support subscriptions, as coverage varies by resource type and may change over time. Subscriptions have a maximum expiry and must be renewed before they expire; a missed renewal creates a notification gap. Incoming notifications must be validated using the subscription's clientState. Duplicate notifications can arrive and must be deduplicated. The notification payload is typically minimal; your handler usually calls the incidents endpoint to retrieve full details.

Neither approach eliminates state management, deduplication or retry logic. Change notifications reduce latency but add subscription lifecycle management.

The hidden work in custom integrations

The retrieval and delivery parts of a custom integration are visible from the start. Several operational concerns only surface after the integration has been running for a while.

Authentication and permissions

An app registration with a client secret requires a rotation process and a secure credential store. If the secret expires over a weekend, notifications stop silently. Certificate-based authentication is more resilient but adds certificate management. The app registration needs an owner, and ownership needs to transfer when the original owner leaves. Delegated (user-based) tokens are not appropriate for background services.

State and duplicate prevention

Polling without state sends duplicate notifications for every incident on every run. State stored in a database or storage account needs backup, recovery and migration planning. Change notifications can deliver the same event multiple times; deduplication requires a stable unique identifier and a record of what has already been processed.

Pagination

A Defender tenant with a meaningful incident history will not return all results in a single API call. Your integration must follow pagination correctly, handle the case where new incidents arrive during a multi-page fetch, and avoid dropping incidents that appear between pages.

Throttling and retries

Microsoft Graph returns HTTP 429 when your request rate exceeds the limit. The Retry-After header tells your client how long to wait. Without retry logic and backoff, throttled calls are silently dropped. Incidents that trigger during a throttle window may not be processed until the next successful polling cycle, or not at all if the state watermark advances past them.

API lifecycle changes

Microsoft Graph APIs are versioned, and older security endpoints are deprecated over time. The legacy /v1.0/security/alerts endpoint has been superseded by /v1.0/security/alerts_v2 and the incidents endpoint. Any integration built against a deprecated endpoint needs migration work when that endpoint is retired. Your team must track the Microsoft Graph changelog and schedule migration work proactively rather than reactively.

Monitoring the notification system itself

A Logic App that fails silently, a function that throws an unhandled exception, a storage account that hits a limit, or an expired credential will all halt your notifications without anyone knowing unless you have explicit health monitoring. The symptom is not an error message; it is a Defender incident that nobody responded to. Missed Microsoft Defender Alerts? Here Is Why It Happens and How to Fix It covers both configuration failures in Defender itself and delivery pipeline failures that produce the same result.

Mobile investigation context

Receiving a notification is not the same as being able to investigate and act on an incident. A Pushover message or a Teams card tells you an incident exists. It does not show you the affected devices, the alert timeline, the evidence items, the related incidents or the recommended response steps. Investigating requires opening the Defender portal on a desktop browser, which is not practical for on-call response. Mobile Security Operations: Handling Defender Incidents on the Go covers why mobile-optimized investigation context matters for first response.

How SOC Anywhere differs

SOC Anywhere is not a general-purpose workflow engine. It is a managed Defender-specific mobile triage platform for teams that want push notifications and investigation context without building and maintaining custom integration infrastructure.

It connects to Microsoft Defender for Endpoint through a one-time Entra ID app registration in your tenant. After that, SOC Anywhere handles authentication, token management, secret rotation, incident polling, deduplication, notification delivery to iOS and Android, and write-back to Defender. There is no Logic App to maintain, no Azure Function to monitor and no custom code to update when Graph API endpoints change.

What SOC Anywhere provides on iOS, Android and the web:

What SOC Anywhere does not replace:

  • a general-purpose automation platform such as Logic Apps, Power Automate or Azure Functions
  • an ITSM system such as ServiceNow, Jira or Freshservice
  • a SIEM or SOAR platform such as Microsoft Sentinel
  • a managed SOC or MDR service
  • enterprise compliance and audit record systems

SOC Anywhere is not a notification relay. It is a full triage interface that starts with a push notification and gives analysts everything they need to understand an incident from their phone, triage it, take action and record their response back into Defender.

Cost: cloud consumption versus engineering time

A Logic App, Azure Function or Power Automate flow polling Microsoft Graph for Defender incidents involves modest direct infrastructure costs. At typical incident volumes, the execution cost of a polling function running every few minutes is low. Azure Function consumption pricing and Logic Apps standard tier costs are both measurable and predictable.

The cost that is harder to measure is engineering time. Building the initial integration takes time. Testing it across the range of incident types, severities and edge cases takes more time. A security review of the app registration, stored credentials and data flow takes more time. Writing documentation so the integration can be supported by someone other than its author takes more time. When a Graph API endpoint is deprecated, migration takes more time. When the original owner leaves and someone inherits the integration, ramp-up takes more time. When notifications stop and nobody knows why, diagnosis takes more time.

None of this is an argument against custom development when the use case genuinely requires it. It is an argument for including engineering time realistically in any build-versus-buy comparison. An integration that costs a few dollars per month to run but requires recurring ownership hours is not free. The relevant question is whether those ownership hours have higher-value uses elsewhere.

Which option should you choose?

Use built-in Defender email notifications if you need a backup channel and your primary notification method is already in place. Do not rely on email as the only signal for operational security incidents.

Use Teams or Slack notifications if you need low-severity awareness in a channel your team actively monitors, and you accept that reading a message does not acknowledge or close the incident in Defender.

Use Pushover if you already have a Defender polling service and want a reliable, low-cost mobile delivery channel. Build the retrieval layer first; Pushover is the delivery end, not the whole integration.

Use Logic Apps or Power Automate if you need to route Defender alerts into existing Microsoft 365 services or business workflows, your team prefers visual tools over code, and you have someone willing to maintain the flow and monitor its health over time.

Use Azure Functions if you need custom business logic that no SaaS tool supports, you have developer capacity to treat it as permanent infrastructure and you are comfortable with the full operational responsibility that brings.

Use Power Apps if you already have a backend Defender sync service, you need a custom interface beyond what existing tools provide, and you have Power Apps licensing and citizen developer capacity to build and maintain the application.

Use SOC Anywhere if you use Defender for Endpoint without a dedicated SOC, your current notification method is too easy to miss or too shallow to act on, you want mobile push notifications with full Defender incident context, and you do not want to build or maintain custom integration infrastructure.

Frequently asked questions

Can I send Microsoft Defender incidents to Pushover?

Yes, with additional components. Pushover accepts incoming messages through its HTTP API but does not retrieve data from Microsoft Graph. You need a separate service, such as an Azure Function or Logic App, that polls Defender incidents through the Microsoft Graph Security API and then calls the Pushover API to deliver the notification. Pushover handles delivery; retrieval, filtering and state management remain your responsibility. Pushover emergency-priority acknowledgement confirms that the notification was received and acknowledged in the Pushover app. It does not acknowledge or update the incident in Microsoft Defender.

Can Power Automate retrieve Microsoft Defender incidents?

Power Automate can call Microsoft Graph through the HTTP action or a custom connector. The Microsoft Graph Security connector in Power Automate is deprecated and should not be used for new implementations; consult the current connector reference for status. A direct HTTP action may require premium licensing and manual OAuth 2.0 token configuration. Flows can retrieve incident data and route it to Teams, email or other connectors, but state management, deduplication and error handling remain your responsibility.

Can I build a Microsoft Defender mobile app with Power Apps?

Power Apps can provide a mobile-accessible interface to Defender data, but it does not retrieve data from Microsoft Graph by itself. You need a backend service to poll incidents, store them in a data source Power Apps can read (such as Dataverse or SharePoint), and write changes back to Defender. Power Apps premium licensing is required for Dataverse and custom connector access. The resulting solution is a custom mobile application with the full build, release and maintenance lifecycle that implies.

Is an Azure Function cheaper than SOC Anywhere?

Direct Azure consumption costs for an Azure Function polling Microsoft Graph at typical Defender incident volumes are low. A complete cost comparison should include development time, testing, security review, monitoring setup, documentation, API migration work when Graph endpoints change, and ongoing ownership time. Whether the total cost is lower than SOC Anywhere depends on how your team values engineering hours and what else those hours could be used for.

Does a custom integration need to poll Microsoft Graph?

Not necessarily. Microsoft Graph supports change notifications for some security resources, which allows Graph to push a notification to your endpoint when a resource changes rather than requiring periodic polling. Consult the current Graph change notifications documentation to confirm which specific security resources support subscriptions, as coverage varies by resource type. Webhook subscriptions must be renewed before expiry. Both polling and change notification designs require deduplication and retry logic.

Does SOC Anywhere replace Power Automate or Azure Functions?

No. SOC Anywhere is a managed triage interface for Microsoft Defender for Endpoint incidents. It replaces the need to build a custom notification and mobile triage layer for Defender specifically. It does not replace general-purpose automation platforms. If you need to automate business processes triggered by Defender incidents, route data to non-Defender systems, or build workflows that involve non-security data sources, Logic Apps, Power Automate or Azure Functions remain the appropriate tools.

Conclusion

Building a custom Microsoft Defender integration is a valid technical choice. Azure Functions, Logic Apps, Power Automate, Power Apps, Pushover and Teams can all serve a role in a Defender incident workflow, and for teams with specific requirements that no SaaS tool covers, custom development is the right answer.

The decision is not about capability. Every option described here can technically work. The decision is about what your team wants to build, own and maintain. Authentication, state, pagination, deduplication, throttle handling, monitoring, API migrations and mobile investigation context all exist regardless of which tool you use. In a custom integration, your team is responsible for all of them. In SOC Anywhere, they are handled as part of the managed service.

For teams using Microsoft Defender for Endpoint without a dedicated SOC, the most common failure is not a missing workflow platform. It is that nobody sees the incident quickly enough, on the right device, with enough context to act. That is the specific problem SOC Anywhere is designed to solve.

SOC Anywhere is available on iOS, Android and the web. Setup requires a one-time app registration in your Entra ID tenant. A 30-day free trial is available with no credit card required.

About the Author: we're building SOC Anywhere, a mobile-first security operations platform designed for teams without 24/7 SOCs. We've spent years working with Microsoft security tools and helping SMEs improve their security posture without enterprise budgets.

Stop building and maintaining Defender notification infrastructure.

SOC Anywhere gives your team real-time Microsoft Defender for Endpoint push notifications and mobile triage out of the box. No Logic Apps, no Azure Functions, no custom code to maintain.

Try it for free — no credit card needed

Related Articles