Six blocks of this series have described products. Endpoint, identity, mail, software as a service, exposure: each one is a thing you can buy on its own, deploy on its own, and run on its own. What has been sitting underneath all of them, doing the work that makes them worth owning together, is not a product in that sense. It has no SKU, no deployment, and no adoption project. It arrives switched on with the first qualifying licence in the tenant, and it is the reason the suite is a suite. Almost every estate I walk into is running it without having decided anything about it.
The playbook, run once per product
Microsoft has consolidated this portfolio into one console by running the same four-step move on every product in it, and watching the pattern repeat is the fastest way to understand where the platform is going next. A capability appears in the unified portal in preview. A redirect from the old console appears and is optional. The opt-out is removed and the redirect becomes forced. The old console stops existing. Defender for Cloud Apps went through it visibly: from 16 June 2024 the redirection toggle was gone and every user of the classic console was rerouted with no way back. Defender for Identity reached the same forced-redirect step on 6 July 2023, after redirection had been switched on by default for every tenant that January. Microsoft never published a decommission date for the classic identity console, which is worth knowing if you go looking for one.
The move currently in flight is the largest of them. Microsoft Sentinel is generally available in the Defender portal, the first workspace in a new tenant has been born there since July 2025, and the Azure portal experience for Sentinel is retired on 31 March 2027. That is a date with real project consequences and it is worth citing carefully, because Microsoft’s own documentation has not caught up with itself. Several current pages still carry the original July 2026 date, which was extended, and at least one manages to state both. The overview and the Defender portal pages carry the correct one. A reader who follows the wrong link lands on a year-old deadline and plans against it.
What that pattern tells you is that the console consolidation is not a user interface preference. It is how capability arrives. Attack disruption, unified hunting, cross-product correlation and the permissions model that governs all of it exist only at the platform layer, which means they exist only in one place. A team that has held onto a per-product console has not kept an old way of working. It has opted out of the capabilities that only exist in the new one, and the exit door is being welded shut on a published schedule.
Incidents are the contract, alerts are the evidence
The single most consequential thing the platform does is decide what an analyst is handed. It aggregates and correlates related alerts into incidents, across every product feeding it, and the incident rather than the alert is what a security operations team works. That sounds like a presentation choice, and it is not. The mechanics underneath it decide which cases an analyst sees as one case, which identifier survives when two become one, and what closing an incident costs you later. None of those are settings, and all of them break processes built on the assumption that an incident is a static object.
The platform decides what an analyst is handed and which alerts belong together. Neither is a setting, and neither is negotiable.
The response half of the platform answers the oldest question in a security operations centre, which is who acts and on whose authority, and it answers it twice in opposite directions on purpose. Automated investigation and response asks permission: automation levels, a queue of pending actions, a human at the gate. Attack disruption asks forgiveness: containment at the incident level, no approval step, compensated for by the fact that every action it takes can be undone. Both are running in your tenant right now. The half that asks permission is being dissolved into the antivirus stack for endpoint, on a date close enough to plan around, which is where the response fabric article takes it.
Authority is a separate question from access
Underneath the console sits a permissions model that has been arriving one product at a time for eighteen months, and the schedule is the clearest evidence available of how this convergence actually happens. New Defender for Endpoint tenants have defaulted to unified role based access control since 16 February 2025. New Defender for Identity tenants since 2 March 2025. New Defender for Office 365 Plan 2 organisations since this month, July 2026, and for those organisations the legacy Email and collaboration roles page is simply not there. One product at a time, new tenants first, with the old model left running for everyone else until they choose otherwise.
That produces an asymmetry worth forcing into the open early. A tenant created last month has a single permissions model and no decision to make. A tenant created three years ago has two models, one of which governs whatever it has activated and the other of which governs everything else, and it will keep both until somebody decides. Nobody stumbles into that decision, because nothing breaks while you postpone it. It surfaces as an access review that cannot answer what a named analyst can actually do, usually during an audit. The authority article argues the model and the decision; its build sheet does the activation.
The best thing in that model is what it does to the most privileged role in the tenant, which turns out to separate authority from access in the one place the industry has always fused them. That sentence is the whole argument of the next article and it is better made there than summarised here.
Where the fabric stops
The platform has hard edges and they are not where people expect. Microsoft Purview projects data loss prevention and insider risk alerts into the incident queue, so an analyst investigates them in the same place as everything else, but policy authoring and the permissions that govern it stay in Purview. Entra ID Protection does the same: identity risk detections flow into the queue and identity data has been pulled steadily into the platform’s schema, but risk policy administration remains in the Entra admin center. Defender for Cloud surfaces in the portal and is administered in Azure.
The rule underneath all three is worth stating once and remembering: this layer unifies response, not governance. You will investigate a data loss prevention alert here and you will change the policy that raised it somewhere else, by a different authority, under a different set of permissions. Teams that read the unified console as a unified administration plane build an operating model that fails at exactly the moment they try to close the loop from an investigation to the control that would have prevented it. That is not a defect. It is a boundary, and designing to it is easier than being surprised by it.
There is a subtler edge inside the platform itself, around how long anything lasts. The portal retains Defender data for a hundred and eighty days for endpoint, identity and cloud apps, and that figure is neither universal nor safe to quote as a property of the suite. Secure Score data is retained for ninety days. Defender for Cloud keeps fourteen. Vulnerability management inventory expires in seven or thirty one days depending on where it came from. Microsoft’s own two current pages for Defender for Office 365 give a hundred and eighty days in one place and a default maximum of thirty in another. And the number people actually mean when they say retention, the window you can write a query against, is thirty days for everything, which is a different mechanism from portal visibility and is called out as an exception on the retention page itself. That thirty day line is where the question of a Sentinel workspace stops being architectural and starts being a budget, which is the Sentinel decision.
The schema is the part that lasts
Consoles get redesigned. What Microsoft has actually built here, and the asset I would protect if I could only keep one, is a normalised event schema that spans endpoint, mail, identity, software as a service, multicloud, the exposure graph and now artificial intelligence agents, in a single query space where a join between two of them is an ordinary thing to write. Every detection your team authors against that schema is an asset the tenant owns rather than a product feature it rents. Custom detections turn queries into first-class detectors with their own entity mapping and their own response actions, which means a query author is one wizard away from isolating a device. That is the argument for taking the permissions model seriously, and it is why the schema article and its build sheet sit where they do in this block rather than at the front.
The portal and the programmatic interface do not share limits, which is where scheduled queries break and which the schema article sets out precisely. The legacy hunting interfaces also have a published end date, so anything still calling them has a migration with a deadline attached rather than a preference.
What varies is signal, not machinery
The licensing shape of this layer is the cleanest argument in the whole series and it closes the loop opened in the series anchor. The platform itself is free once you qualify. Any single one of a long list of licences lights it up, and that list is broad enough that most estates already qualify several times over. There is no SKU for the permissions model. There is no SKU for correlation, and none for attack disruption. What varies with your licensing is not whether the machinery runs but how much signal it has to work with, which is a genuinely different proposition from the one most procurement conversations assume.
The distinction that matters operationally is between entitlement and coverage. One qualifying licence lights the disruption engine for the tenant, and every individual action it can take has a hard product dependency behind it, so what you are actually able to do during an incident is decided by how far you deployed rather than by what you bought. The response article works that through action by action, because it is the difference between a platform that can see an attack and one that can act on it.
Two things sit outside that free machinery and they fail differently. Security Copilot is metered. Since November 2025, Microsoft 365 E5 and E7 include four hundred security compute units per month for every thousand paid user licences, capped at ten thousand a month and scaling proportionally below a thousand seats, so four hundred users receive a hundred and sixty units. Those allocations reset monthly and do not carry over. Microsoft has said that use beyond the allocation will be throttled at a future date, with pay as you go available at that point and thirty days of notice first, which means today the allocation is a ceiling on capability rather than a bill. Defender Experts is the other posture entirely: five services, all form-gated, all sales-priced, none of them on a public price list. The last article in this block takes that boundary apart, including the part where your own deployment posture limits what a service you are paying for is permitted to do.
What this block covers, and what it closes
Eight articles follow, in three pairs and a close. Authority comes first, because every other decision in this block is bounded by who is allowed to make it, and it carries the build sheet that activates the model and wires the tenant-level settings that belong to no pillar. Response comes second, covering incidents, disruption, and the retirement of a component many teams still think of as their automation strategy, with a readiness build sheet underneath it. The schema comes third with its own build sheet, taking a saved query through to a governed detection. Then the Sentinel decision, which most people think the retirement deadline makes for them and it does not. The licensing boundary closes the block.
It also closes the series. Six blocks ago this started with the observation that Microsoft 365 E5 contains a security suite most organisations own and few operate, and that the suite is not a product but a set of products with something underneath them. That something is what this block describes, and the honest summary of it is that the platform layer is the part you already own and have never configured. The pillars were the deployment work. This is the design work, and it is mostly decisions rather than settings: who holds authority, how wide your deployment goes, what you let act without asking, and how long you keep anything.
One thing is deliberately out of scope here and will get its own series. Everything this block says about Microsoft Sentinel is aimed at a single question, which is what the fabric looks like with and without a workspace and why that question now has a deadline. What follows here is the last of the platform, starting with who is allowed to do any of it.
Defender XDR
‹ Previous: [D 6.3] Secure Score: The Number the Board Sees
Next: [D 7.1] Authority in One Portal: Unified RBAC and the Three Tiers of Control ›
