10 mins

Managed Security for Microsoft 365 and Azure: What to Verify

Last Updated

August 31, 2026

Key Takeaways

Managed security for a Microsoft estate means continuous monitoring and response across seven surfaces, covering endpoint, identity, email, device management, SaaS, cloud infrastructure and the SIEM layer, not endpoint detection alone.
Device management is the surface most often left out of scope, even though Intune compliance state feeds the conditional access policies that protect identity.
Agentless does not mean your security data stays in your tenant. Of the five delivery models below, only two leave detection content and log history inside your own environment.
Sentinel workspace ownership decides whether you keep your log history and detection content if you change provider.
Co-managed delivery is not universally available, and at least one major provider states plainly that it does not offer it.
Delegated permissions determine what a provider can actually do in your tenant, so agree the response actions before onboarding rather than during an incident.

Managed security for a Microsoft 365 and Azure tenant has to cover seven surfaces: endpoint, identity, email, device management, SaaS, cloud infrastructure and Microsoft Sentinel. Most managed detection and response (MDR) shortlists cover the endpoint slice and stop. This page sets out what full tenant coverage looks like, how the major providers actually deliver it, and what to verify before you sign.

‍

The Seven Surfaces a Microsoft Estate Exposes

A Microsoft 365 and Azure tenant exposes seven distinct security surfaces, and each one produces its own telemetry, requires its own detection logic, and can be scoped in or out of a managed service contract independently. Most managed detection and response proposals cover two or three of them well. The table below sets out what each surface is, what monitoring it actually requires, and what providers commonly leave out.

Surface	Microsoft product	What monitoring it requires	Commonly excluded from MDR scope
Endpoint	Microsoft Defender for Endpoint	Process, file and network telemetry from managed devices, with device isolation available as a response action	Servers and Linux endpoints, where licensing differs from user devices
Identity	Microsoft Entra ID	Sign-in and audit logs, risky user and risky sign-in detections, privileged role changes	Full risk detection detail. Without Entra ID P2 the detections still fire but arrive as "Additional risk detected" with no supporting context, and risk-based conditional access is unavailable
Email and collaboration	Microsoft Defender for Office 365	Mail flow telemetry, post-delivery detonation verdicts, user-reported phishing, mailbox rule changes	Post-delivery remediation and mailbox rule auditing, often left with the customer
Device management	Microsoft Intune	Device compliance state, configuration drift, enrolment events, and the compliance signal feeding conditional access	Almost always. Intune is treated as an IT function rather than a security surface
SaaS applications	Microsoft Defender for Cloud Apps	App discovery, OAuth consent grants, session and file activity across connected SaaS	OAuth application consent monitoring, one of the most exploited paths into a tenant
Cloud infrastructure	Microsoft Defender for Cloud	Posture findings, workload alerts across Azure subscriptions, container and storage telemetry	Multi-cloud posture and cloud security posture management, frequently priced separately
SIEM and correlation	Microsoft Sentinel	Log ingestion across all six surfaces above, correlation rules, automation playbooks, retained history	Custom detection engineering and ingestion cost management, often the customer's problem

Device management is the surface to check first. Intune compliance state is what conditional access evaluates before it grants a token, so a device that silently falls out of compliance becomes an identity risk rather than a device risk. A provider covering endpoint and identity while ignoring Intune has a gap sitting between two surfaces it claims to own. When you scope a shortlist, ask for managed Defender for Endpoint coverage and Defender for Office 365 monitoring to be quoted as separate line items rather than bundled, so exclusions surface before contract rather than after. CyberQuell operates across all seven surfaces listed above.

‍

What Coverage Actually Means Per Surface

Coverage is three separate commitments, not one: monitored means the provider ingests the telemetry, detected means it maintains tuned detection logic against that telemetry, and responded means it can take a containment action without waiting for you. A provider can honestly claim to cover a surface while doing only the first. Ask for coverage to be stated per surface at each of the three levels.

Surface	Monitored	Detected	Responded
Endpoint	Device telemetry ingested continuously	Tuned detections beyond stock Defender alerts	Device isolation without waiting for approval
Identity	Sign-in and audit logs ingested	Detections for token theft, consent abuse, privilege escalation	Account disable and session revocation
Email and collaboration	Mail flow and detonation verdicts ingested	Detections for post-delivery threats and mailbox rule abuse	Message purge from delivered mailboxes
Device management	Compliance state and enrolment events ingested	Detections for compliance drift and enrolment abuse	Device marked non-compliant or blocked from access
SaaS applications	App and session activity ingested	Detections for OAuth consent grants and anomalous file activity	App revocation or session termination
Cloud infrastructure	Posture findings and workload alerts ingested	Detections for identity and workload attack paths	Resource isolation or credential revocation
SIEM and correlation	Cross-surface log ingestion	Custom analytics rules and cross-surface correlation	Automated playbook execution

Most proposals sit in the first column across all seven rows and the third column in none. That gap is where the word "managed" does most of its work. The same distinction applies to any provider, not just Microsoft-estate ones, and it is worth reading alongside what separates a monitoring SOC from a response-driven SOC. Device management is the surface most often monitored with no response authority attached, so ask specifically about managed Intune device compliance when you scope.

‍

How Microsoft MDR Is Actually Delivered: Five Models Compared

Agentless does not mean your security data stays in your tenant. Four of the five delivery models below require no proprietary agent, and only two of those four leave detection content and log history inside your own environment. The question that decides portability is not whether software gets installed, it is where detection runs and what you keep if you leave.

Model	Provider	Where detection runs	What this means for you
Your Sentinel, delegated access	CyberQuell	Your own Sentinel workspace, reached through Azure Lighthouse	Workspace, detection content and log history stay in your subscription, and you can revoke provider access at any time
Your Sentinel, provider-operated	BlueVoyant	Your own Sentinel instance	Detection content and log history stay in your environment
Dual-plane	eSentire	Detections in your Sentinel, correlation on Atlas	Response routed to whichever plane has better control
Provider platform, agentless	Expel	Expel Workbench, Expel detection engine	API-connected and fast to onboard, but telemetry leaves the tenant
Provider platform, no co-management	Arctic Wolf	Aurora Platform, provider-owned cloud data lake	Co-management is explicitly not offered. Access is via portals, reports and log search

Arctic Wolf, the most visible provider in this category, states in its own company FAQ that it delivers security operations rather than co-management, that all solutions run on its proprietary cloud-based platform managed by its Concierge Security Teams, and that customer access comes through portals, reports and log search tools. Most mid-market buyers evaluating a Microsoft estate assume co-management is available and never ask. That assumption is where shortlists end up at the bottom of the table without anyone choosing it.

The other three publish their architecture openly: Expel connects to the Microsoft stack through APIs, eSentire runs Sentinel alongside its Atlas platform while maintaining detections inside your workspace, and BlueVoyant operates inside a client-owned Sentinel environment. Establish which model a provider is proposing before you compare price, because it decides what you are able to take with you. CyberQuell operates the first: our analysts work inside your workspace under Azure Lighthouse delegation, which is scoped, audited, and revocable by you.

‍

Microsoft Partner Designations and What Each One Proves

Microsoft's four security-relevant designations prove different things, and only two involve an independent audit of how a provider actually runs security operations. The other two measure commercial performance and ecosystem participation. Treat them as separate signals rather than a single badge count, and ask which one a provider means when it calls itself a Microsoft security partner.

Designation	What Microsoft requires	What it proves about security operations	How to verify it
Solutions Partner for Security	A partner capability score of at least 70 out of 100, with points in every metric across performance, skilling and customer success	Certified headcount and a working customer base on Microsoft security workloads. It does not assess service delivery	Microsoft partner directory listing, or ask for the Partner Center designation date
Microsoft Verified MXDR Solution Status	MISA membership first, then an independent review of the MXDR service by Microsoft Security engineering	The closest thing to an audit of the managed service itself, rather than of the company selling it	The Microsoft MXDR partner listing. Ask for the verification date, since services change
MISA membership	Nomination, then integration of the provider's solution with Microsoft security technology	Ecosystem participation and early access to Microsoft security engineering. Not a delivery standard	The MISA member catalogue
Azure Expert MSP	Approved application followed by a third-party audit, with annual revalidation on the anniversary date	Audited managed-service delivery on Azure, though not security-specific	Microsoft's Azure Expert MSP listing. Ask when it was last revalidated

Verified MXDR Solution Status is the one to weight most heavily, because it is the only designation on this list that examines the managed detection and response service a provider will actually deliver to you.

‍

What to Verify Before Shortlisting

Six things decide whether a Microsoft-estate engagement works, and none of them appear in a standard MDR datasheet. Ask each one before the shortlist, not during contract review, because the answers are cheap to give early and expensive to renegotiate late.

Who owns the Sentinel workspace. This single answer determines whether you keep log history and detection content if the relationship ends. Ask whether the workspace sits in your Azure subscription or the provider's. If it is theirs, ask what an exit looks like and get the answer in writing.
Log retention terms and who pays ingestion. A provider absorbing ingestion cost has an incentive to filter log sources, which turns a coverage decision into a cost decision. Establish the retention period, whether it meets your regulatory obligation, and whether ingestion appears on your Azure bill or theirs.
Cross-tenant support. Multi-tenant estates are common after acquisitions and routinely priced as an afterthought. If you run more than one Microsoft tenant, ask how the provider monitors across them and whether it costs extra.
Third-party connector coverage. A provider only monitors the connectors it has built and maintains tuned detections for, not everything Sentinel can ingest. Ask which of your non-Microsoft tools are covered by maintained detection logic rather than raw ingestion.
Raw KQL access. Direct query access is what lets you verify a provider's findings independently. Ask whether your team can query the workspace directly or is limited to the provider's reporting layer.
GDAP scope and duration. Standing global administrator access is a red flag. Ask which Entra roles the provider requests under Granular Delegated Admin Privileges, for how long, and how you revoke them.

These six are Microsoft-specific. For the criteria that apply to any provider, our guide to evaluating a SOC provider beyond its tooling covers the general ground.

‍

Who Owns the Sentinel Workspace

Whoever owns the Sentinel workspace owns your log history, your detection content, and your ability to leave. Three models exist, and providers rarely state which one they operate unless asked directly.

Provider-owned

The workspace sits in the provider's Azure subscription. Ingestion cost is bundled into the monthly fee, which makes budgeting simple and hides what you are actually paying for storage. On exit you leave with reports, not raw logs, and the detection rules built for your environment stay behind. Ask what an export looks like, in what format, and how long it takes.

Customer-owned with delegated access

The workspace sits in your subscription and the provider reaches into it, typically through Azure Lighthouse, which grants scoped access without creating accounts in your tenant. Ingestion appears on your Azure bill, so costs are visible and controllable. On exit you revoke the delegation and keep everything: history, analytics rules, playbooks, workbooks.

Co-managed

The workspace is yours, and both parties author detection content in it. This works where you have internal security capability worth retaining, and it fails where responsibility for tuning is left undefined. Agree in writing who owns which analytics rules before go-live.

With some providers the question does not arise at all. Where co-management is not offered, there is no shared workspace to own, and the answer is provider-owned by default whether or not it is presented that way.

The evidence consequence matters most in a regulated environment. If an auditor asks for twelve months of correlated log data, a provider-owned workspace means asking permission for your own records. Our managed Microsoft Sentinel SIEM service uses the second model for that reason.

‍

Response Authority: Who Can Act in Your Tenant

Response authority splits along a line most buyers never see: device and mail actions run on Defender permissions, while every identity action requires an Entra directory role that security teams are usually not granted. A provider can isolate an infected laptop in seconds and still be unable to disable the compromised account driving the attack.

Response action	Permission it requires	Where it is granted	Common default
Isolate a device	Response (manage)	Defender unified RBAC	Provider acts without approval
Run live response on a device	Basic or Advanced live response (manage)	Defender unified RBAC	Provider acts without approval
Quarantine or release mail	Email and collaboration quarantine (manage)	Defender unified RBAC	Provider acts without approval
Disable a user account	User Administrator	Entra ID directory role	Escalated to your team
Revoke active sessions	User Administrator, or Privileged Authentication Administrator against admin accounts	Entra ID directory role	Escalated to your team
Block sign-in	User Administrator	Entra ID directory role	Escalated to your team

The bottom three rows are where incidents are actually lost. Token theft and session hijacking are identity attacks, and containing them means revoking sessions, not isolating hardware. In one multi-phase business email compromise investigation, stolen session tokens and malicious Outlook rules survived multiple credential resets, which is precisely the failure mode a device-only response cannot reach. If your provider holds Defender permissions but no directory role, its response to the attack type that matters most is to phone you and wait. Agree that boundary before onboarding, and put the out-of-hours escalation path in writing.

Note that Microsoft's unified RBAC model is now the default for new Defender for Endpoint and Defender for Identity tenants, and from July 2026 for new Defender for Office 365 Plan 2 organisations. Older tenants may still run the legacy per-product model, so ask which one yours uses before mapping permissions. The full permission definitions are published by Microsoft, which means every row above is checkable against primary documentation rather than a vendor's description of its own service.

‍

What SLAs to Ask a Managed Security Provider For

A commitment is only checkable if it names what starts the clock, what stops it, and what happens when it is missed. Most published response times name none of the three. Six commitments are worth insisting on, and the test for each is whether a disputed month could be settled from evidence rather than argument.

Commitment	What makes it checkable
Triage acknowledgement	The commitment must name which alert severities it applies to and whether the clock starts at alert generation or at analyst pickup. It must also name where the timestamp is recorded, so the figure can be audited later
Containment authority window	The commitment must state the maximum time between confirming an incident and taking a containing action, separately from acknowledgement. A fast acknowledgement with no authority to act is not containment
Escalation tiers and named contacts	The commitment must name who is contacted at each severity and by which channel. It must also state what happens when the first contact does not answer
Coverage hours and holiday handling	The commitment must state whether cover is analyst-staffed or on-call, and in which time zones. It must also name which public holidays run reduced staffing
Reporting cadence	The commitment must state what arrives and how often. It must also state whether reports include alerts closed as false positives or only confirmed incidents
Onboarding-to-live target	The commitment must define what "live" means. Connectors deployed is not the same as detections tuned, and tuned is not the same as monitored

Vendors publish headline figures against these. eSentire states a Mean Time to Contain of under 15 minutes for its Microsoft services, and Expel a mean time to remediate under 15 minutes. Both are real commitments, and both raise the same question you should ask any provider: measured from what event, against which severities, and reported where. Ask for a sample monthly report from a live account, redacted, before signing. A provider that measures what it claims will have one ready.

‍

Onboarding: What the First 30 Days Should Produce

Onboarding produces artefacts, not activity. Ask a prospective provider what will exist at the end of thirty days that did not exist at the start, and hold the answer against these six deliverables.

Asset inventory, week one. A reconciled list of devices, users, tenants and Azure subscriptions in scope, with anything unmanaged flagged rather than quietly excluded.
Log source enumeration, week one. Every connector enabled, with the ones deliberately left off named and the reason recorded. Silent omissions become blind spots.
Baseline tuning, week two. Alert volume measured before and after suppression, so you can see what was turned down and why.
Escalation matrix, week two. Named contacts by severity, with out-of-hours routing and a fallback when the first contact does not answer.
Break-glass test, week three. A live rehearsal of one response action end to end, including whichever identity actions sit outside the provider's permissions.
First report, week four. Delivered on the agreed cadence, covering the full period rather than a partial month.

If nothing on this list has a date against it by the end of week one, onboarding is drifting. For the longer view, our account of the first 60 days of a managed SOC engagement covers what follows once monitoring is stable.

Working out what a Microsoft-estate provider would actually cover in your tenant? Tell CyberQuell what you have monitored today and our SOC monitoring and response team will come back with a proposal scoped to the surfaces you are missing.

‍

Data Residency for Microsoft Workloads

Data residency in a Microsoft estate is set per workload, not per tenant, so no single statement covers the whole estate.

Microsoft Sentinel: data sits in the Azure region of the Log Analytics workspace, chosen when the workspace is created. This can differ from your tenant's home region.
Microsoft Defender for Endpoint: data is stored either in the tenant geolocation identified during provisioning, or in the region set by whichever online service processes it. Retention is 180 days, and data is erased no later than 180 days after a contract ends.
Microsoft 365 workloads: check Microsoft's published data location for your specific tenant rather than assuming it follows your billing country.
Across all of them: some threat intelligence enrichment and cross-tenant analytics are processed outside your chosen region regardless of workload settings.

Ask a provider where each of these lands before onboarding, not after. Microsoft publishes data storage and retention terms per workload, so the answers are checkable rather than something you take on trust.

‍

Where Microsoft's Own Service Fits

Microsoft sells a managed service for its own stack, now called Defender Experts MDR after being renamed from Defender Experts for XDR. It is a real option for a Microsoft-first estate, and it answers a narrower question than this page does. Its analysts act only where you have granted Security Operator access and only on assets you have scoped in, and for non-Microsoft telemetry they provide recommendations rather than taking action directly. That boundary is the comparison. Whether it fits depends on how much of your estate is Microsoft and how much response authority you want to delegate, which is a comparison worth running against the surfaces and permissions set out above.

‍

Final Thoughts

The decision this page has been building toward is not which provider is best. It is which of the five delivery models you are willing to live with, because everything else follows from it: who holds your log history, what your provider can act on without waking you, and what you keep if you leave. Answer that first and the shortlist shortens on its own. A provider that cannot state its model plainly in a first call is telling you something useful.

If you would rather see that mapped against your own tenant than work it out in the abstract, book a call with CyberQuell. Tell us what you have monitored today and we will come back the same business day with a proposal scoped to the surfaces you are missing.

Last Updated:

August 31, 2026

FAQs

Find answers to commonly asked questions about our cybersecurity solutions and services.

What does managed security for Microsoft 365 include?

At minimum it covers continuous monitoring and response across endpoint, identity, email, device management, SaaS applications, cloud infrastructure and the SIEM layer. Many providers scope only endpoint and email. Ask for coverage to be quoted per surface, since a provider can claim to cover Microsoft 365 while monitoring two of the seven.

‍

Do I need a Microsoft partner to manage my tenant?

No. Any provider you grant delegated access to can manage a Microsoft tenant, partner status or not. What partner designations tell you is whether Microsoft has independently assessed the provider, and only some designations assess the managed service rather than the company's commercial performance.

What is Microsoft Verified MXDR Solution Status?

It is a designation given after Microsoft Security engineering reviews a provider's managed detection and response service, with membership of the Microsoft Intelligent Security Association as a prerequisite. It is the only common Microsoft designation that examines the service itself rather than certification counts or revenue. Ask when a provider's status was last verified, since services change.

Who should own the Sentinel workspace?

In most cases you should, because whoever owns the workspace owns the log history and the detection content built for your environment. If the provider owns it, you leave with reports rather than raw logs. Provider-owned is workable, but agree the export format and timeline in writing before you sign.

Does the provider run detection in my Sentinel instance or on their own platform?

It varies by provider and it is worth asking directly. Some operate entirely inside your Sentinel workspace, some ingest your telemetry into their own platform, and some do both. Being agentless does not mean your data stays in your tenant, which is the assumption most buyers get wrong.

Does Microsoft Defender for Endpoint cover identity attacks?

No. Defender for Endpoint monitors devices. Identity attacks against Microsoft Entra ID are covered by Microsoft Entra ID Protection, and attacks against on-premises Active Directory by Microsoft Defender for Identity. A provider covering only endpoint has no visibility of token theft or session hijacking.

Do MDR providers monitor Intune device compliance?

Usually not. Microsoft Intune is commonly treated as an IT function rather than a security surface and left out of scope. That is a gap worth closing, because device compliance state feeds the conditional access policies that protect identity, so a device drifting out of compliance becomes an identity risk.

What permissions does a provider need to respond in my tenant?

It depends on the action. Device isolation and mail quarantine run on Microsoft Defender permissions, while disabling an account, revoking sessions or blocking sign-in require an Entra ID directory role such as User Administrator. A provider holding only Defender permissions can isolate a laptop but cannot disable the compromised account.

Latest