For a decade the question was whether to buy a security information and event management system, and the answer turned on budget. That framing has quietly stopped describing reality. New workspaces are created inside the Defender portal by default, the separate experience has a retirement date, the tenant you already have comes with an ingestion allowance most organisations have never claimed, and two response capabilities in the previous articles only work if a workspace exists. The decision is still real. It is just no longer the decision people think they are making.
Thirty days, one hundred and eighty days, and why the difference decides this
Start with the sharpest fact in this whole block, because everything else follows from it. Endpoint, identity and cloud apps data is visible in the portal for a hundred and eighty days, with other data types carrying their own shorter figures as the anchor sets out. All of it is queryable through advanced hunting for thirty days and no longer. Those are two different mechanisms and Microsoft states the exception explicitly on its own retention page. An analyst investigating something that began four months ago can see evidence on an entity page and cannot write a query against it, which is precisely the moment in an investigation when a query is what you need.
That thirty day line is the boundary this article is about. Everything a workspace adds falls into one of two categories: history beyond the line, or signal from outside the first-party estate. If neither of those is a problem you actually have, the honest answer is that you do not need a workspace and nobody should sell you one. If either is, the workspace extends the same query space described in the anchor rather than replacing it, and it now lives in the same console.
What you already have
Without a workspace, a tenant with an appropriate licence gets cross-product correlation into unified incidents, automatic attack disruption, thirty days of hunting across the full schema, custom detections with response actions, and the portal retention above. That is a working detection and response capability, and I want to be blunt about it because a lot of consulting revenue depends on people not being told: for a Microsoft-only estate with no compliance retention requirement, that is enough, and the organisations that struggle are not the ones without a workspace but the ones who never operated what they had.
The workspace adds five things and they are worth separating rather than bundling. Retention past thirty days, on tables you choose. Ingestion of anything that is not Microsoft’s, which in most estates means the firewall, the network devices, the line of business application and whatever the identity provider is if it is not Entra. Orchestration, meaning playbooks and the automation that fires them. The analyst furniture that has no equivalent on the Defender side: watchlists, user and entity behaviour analytics, and the threat intelligence object store. And, as covered in the response article, the only documented paths to suspending an Okta account or attaching a deny policy to an AWS principal during a disruption, both of which are in preview and both of which need not merely a connected workspace but one actually ingesting the relevant logs.
The thirty day line is the whole decision. Everything a workspace adds is either history past it, or signal from outside the estate that produced it.
The grant nobody claims
There is an ingestion allowance attached to the licence you probably already hold, and in a decade of these conversations I have met very few organisations that knew about it. Customers on the top-tier Microsoft 365 suites, which now includes the E7 tier alongside E5, A5, F5 and G5 and their security variants, receive a data grant of up to five megabytes per user per day for ingesting a named set of Microsoft 365 data. On a three thousand seat estate that is fifteen gigabytes a day, applied automatically to the bill, for exactly the data a Microsoft-centric security team wants retained.
The qualifications matter because this is a number people put into business cases. The data types are specific rather than general: directory sign-in and audit logs, shadow information technology discovery, information protection logs, and the advanced hunting tables from the Defender products. It is not a general purpose allowance and it will not cover your firewall. The eligibility gate includes the agreement type, with enterprise, enterprise subscription and cloud solution provider agreements named, so a customer buying through other routes is not on the list. And the figures live on a pricing offer page rather than in the documentation, with no revision history and no stated end date, which means the correct thing to say is that there is no published end date rather than that the grant is permanent.
Separately from the grant, a set of tables is ingested free of charge regardless: activity logs from the subscription, the service’s own health data, the Office 365 audit log including SharePoint, Exchange administration and Teams, and security alerts from every Defender product. The caveat that matters is stated plainly and is the reason the grant exists: the alerts are free and the raw logs underneath several of those products are not. So a workspace ingesting only alerts is close to free and close to useless for hunting, and a workspace ingesting the raw telemetry is where the grant starts earning.
Put those together and the framing I would take into a budget conversation is that having no workspace at all is now the position requiring justification, because a meaningful quantity of ingestion is already paid for and two of the platform’s own response actions are gated behind having one.
The retention answer is a lake, and it is metered differently
The retention question is answered by the two-tier model rather than by buying more of the same tier. The analytics tier is the hot data your rules and hunting run against, thirty days by default and extensible. The lake tier is long-term storage for up to twelve years, and the important property is that data in the analytics tier is mirrored into the lake as a single copy at no ingestion charge. So the choice per table stops being keep or discard and becomes how hot and for how long.
The economics invert in a way that catches people used to a traditional platform. Storing is cheap, billed on a uniform six to one compression assumption, so six hundred gigabytes of raw data bills as a hundred. Touching is what costs: queries are charged per gigabyte scanned uncompressed, and the analytics work runs on compute hours in fixed pools. A team that lifts and shifts a decade of retention habits into this model without changing how it queries will be surprised by the bill, and the surprise will arrive from the query meter rather than the storage one. The Defender hunting tables themselves can be directed into the lake tier, which is the first-party answer to wanting more than thirty days of endpoint telemetry, and it is worth knowing that the thirty days in the analytics tier remain included when you do.
Onboarding breaks things, and Microsoft says which
Every incident’s provider becomes the platform rather than the workspace, so any automation conditioned on the provider stops discriminating. The incident description field disappears from the table that ticketing integrations read, which for a service management integration is not a cosmetic loss. Automation rules triggered on alert creation act only on workspace alerts unless you move to the newer trigger. There is a latency of up to ten minutes between an incident appearing and an automation rule running, plus a batching window where several changes inside five to ten minutes collapse into one update and the intermediate states are simply lost, which is fatal to any workflow that depends on observing sequential state changes. Alerts and incidents stop being encrypted with your own keys, although the rules and content around them continue to be. The correlation engine may rename and merge incidents you already have, which is why Microsoft advises against conditioning automation on incident titles. And the correlation rule that used to do this job in the workspace is switched off, because the platform’s engine replaces it.
Onboarding is still right. It is an integration project with a test plan rather than a portal migration, and the documented list above is what the test plan gets written from. There is a further change with a date that has already passed and that catches automation specifically: account entity naming was standardised on 1 July 2026 so that the account name is now the user principal name prefix only, with the full name and suffix moving to separate fields. Anything comparing on a full user principal name broke that day.
The deadline, and the two pages that will mislead you about it
The Azure portal experience for Microsoft Sentinel is supported until 31 March 2027, after which customers are redirected to the Defender portal and it is the only experience. That date was extended from an earlier one, and the extension is the source of a documentation hazard worth naming precisely because a reader who plans against the wrong date loses eight months. The overview page and the Defender portal page carry the correct date and are the ones to cite. The best practices page still tells you, in its body, that everyone will be redirected by July 2026, a date that has already passed. And one of the two what’s new feeds still carries an uncorrected July 2025 entry announcing the original date, while its sibling feed carries the same entry with a correction note attached.
Meanwhile the default has already flipped underneath the decision. Since July 2025, a customer creating the first workspace in a tenant has it onboarded to the Defender portal automatically, provided the person doing it holds the right subscription rights. Existing customers are not being forced yet, which means the tenants still creating workspaces in the old experience are choosing to, and will be the last cohort to migrate under a deadline rather than at their own pace.
One more inversion that undoes the traditional framing entirely. Microsoft Sentinel in the Defender portal does not require Defender XDR and does not require an E5 licence. A customer with no Defender products at all can run it there, and transitioning costs nothing beyond the consumption they were already paying. So the old mental model, in which the platform is the Microsoft-shop product and the workspace is the grown-up security information and event management system you graduate to, has the relationship backwards. They are one console with two billing models, and the workspace is the part that meters.
How I would actually decide it
The two questions that settle most cases are the two categories above, and a team answering no to both should run without a workspace, operate what it has, and revisit when one of them changes. That is a defensible architecture rather than a compromise. What is left after that is shape rather than whether: which tables need to be hot and which merely need to exist, because that split is where the cost is decided, and whether you need orchestration, which is the question that separates a retention project from a rebuild of how the team works, because playbooks bring a development lifecycle with them and teams routinely underestimate that.
What I would not do is let the deadline make the decision. The retirement of the old experience changes where a workspace is operated, not whether you need one. A team that onboards a workspace it did not need in order to meet a date has bought a bill and a migration, and the date was not talking to them.
The scoping note in the anchor still holds: connector architecture, analytics rule design, orchestration and cost engineering belong to a series of their own, written from the assumption that this decision is already made. What remains here is the last boundary in the block, which is the one between what you own, what you are metered for, and what you have to negotiate with a salesperson: the final article. The schema arguments this article leans on are in the schema article if you have arrived here first.
Defender XDR
‹ Previous: [D 7.3.1] Build Sheet: From Saved Query to Custom Detection
Next: [D 7.5] The Metered and the Negotiated: Security Copilot and Defender Experts ›
