Microsoft Defender operations for MSPs
Connect customer incident context, device vulnerabilities and service tickets. Give technicians a repeatable Defender review workflow without losing sight of which customer or device needs attention.
For MSP administrators and security technicians. Self-hosted MSPControl; available data and actions depend on your version, customer setup, permissions and Microsoft licenses.
Microsoft Defender multi-tenant management is the work of reviewing and responding to Defender findings across separate customer tenants. MSPControl supports specific parts of that work: customer incident counts, device security findings, managed-device deployment settings and configured ConnectWise incident workflows. Each customer retains its own Microsoft connection, licensing, permissions and resulting state.
From findings to follow-through
Start with the supported surface that owns the work. Review, configuration, ticket synchronization and incident response are different operations.
Use the customer security view to review available Defender incident counts alongside customer context. Treat counts as a starting point for triage; they are not the full incident investigation or an all-customer live queue.
With the ConnectWise integration and incident sync task configured, create linked tickets from supported Defender incidents. Keep the customer mapping, incident identifier and ticket ownership clear so the next technician can continue the work.
Open the matched device to review Defender recommendation names, weaknesses, related components, vendors and remediation types. Use the findings to decide the next action; a recommendation does not apply its own fix.
Inspect available CVE names, severity, publication dates and descriptions on the matched device. Combine this with device and software context, then validate the remediation and refreshed source data.
Use managed-device profile settings for the available Defender deployment and sample-collection options. Check the effective policy, supported Windows environment and Microsoft onboarding prerequisites before rollout.
Where incident auto-close is configured, understand which status change is being synchronized and what access it requires. Read the task result and confirm the actual Defender incident state instead of treating a submitted request as completion.
Missing data is not an all-clear. An empty view can mean the device was not matched, the service is unavailable, permissions or licensing do not expose the signal, or collection failed. Confirm the source and its freshness before deciding that no action is needed.
Customer boundaries
Work from the intended MSPControl organization and matched device. Do not assume that connecting one customer grants access to another.
Read-only Microsoft 365 integration limits Defender status changes. Review write permissions and test mode before enabling incident auto-close.
Use configured incident-to-ticket mappings and task results to track follow-up. Keep the incident identifier and investigation decisions available to the next technician.
Check the incident or device in the relevant Microsoft service when deeper investigation or final confirmation is required.
Current boundary: these workflows do not promise a universal all-tenant incident console, cross-tenant advanced hunting, automatic remediation of every vulnerability, complete Defender XDR or Sentinel coverage, or a replacement for your security operations team. A resolved ticket or incident status does not by itself prove that a threat has been removed.
Choose the right surface
| Need | MSPControl workflow | What still needs verification |
|---|---|---|
| Customer incident overview | Available incident counts in customer security context. | Source availability and the underlying incident details. |
| Incident ownership and follow-up | Configured ConnectWise incident synchronization and linked service records. | Company mapping, ticket assignment, sync warnings and actual Microsoft status. |
| Device exposure review | Recommendations and vulnerability findings on matched managed devices. | Collection freshness, applicability, remediation and refreshed results. |
| Protection deployment | Supported managed-device Defender profile settings. | Effective policy, eligible licensing, onboarding and protection state. |
| Full attack investigation | Customer, device and ticket context supports the response process. | Use native Microsoft investigation and response tools where the required operation is not exposed in MSPControl. |
Safe rollout
Confirm the Microsoft service and license, required access, device onboarding and customer mapping. Run the selected workflow with its test controls where available. Review errors and warnings, verify the real result, and only then repeat the configuration for additional customers. The same review process does not guarantee identical data or permissions in every tenant.
Configuration and verification
Connected operations
Common questions
It means using MSPControl customer and device context to review supported Defender information and operate configured integrations across the customers you manage. The verified surfaces include customer incident counts, device recommendations and vulnerabilities, deployment settings, and ConnectWise incident synchronization. It is not a claim of a single all-tenant Defender incident console.
No. MSPControl provides administrative and operational workflows around connected Microsoft services. Microsoft Defender licensing, supported platforms, onboarding, consent and permissions remain separate prerequisites.
Yes, the configured Defender incident synchronization task can create and link ConnectWise tickets for supported customer organizations. Customer mapping, integration policy, task options, Microsoft access and source availability determine the result. Review task warnings and verify both records.
No. The configured auto-close path can update the corresponding Defender incident, but it depends on its settings, the closed ticket status, the incident state, test mode and write permissions. The current implementation skips the Defender write for a read-only Microsoft 365 integration. A ticket status is not evidence that remediation is complete.
No. First establish that the expected source was available, authorized and collected for the correct device and tenant. An unmatched device, missing license, collection error or stale data can leave a view empty. Investigate availability before drawing a security conclusion.
No. Microsoft offers its own multitenant experience in the Defender portal. MSPControl is a separate self-hosted platform connecting verified customer, device, ticket and reporting workflows. Use the Microsoft portal for native incident investigation and response capabilities that are not exposed in your MSPControl installation.
Self-hosted. Free license available. No credit card required.
