Microsoft moved Defender Threat Intelligence into Defender XDR and Microsoft Sentinel. The intelligence remains. Your bookmarks, feeds, runbooks, access and cost assumptions may not.
Owner: SOC lead
A portal retirement looks like a product change. During an incident, it becomes an operating risk. If an analyst opens an old bookmark, an automated feed points at a retired path or a runbook assumes the previous interface, investigation time is lost when it matters most.
What changed
Microsoft completed the convergence of Defender Threat Intelligence into Defender XDR and Microsoft Sentinel. The final phase became generally available on 1 August 2026. The standalone Microsoft Defender Threat Intelligence experience retired on the same date.
Threat reports, actor profiles, campaigns and indicators now sit inside the security tools where teams investigate incidents. That can improve context because the research is closer to the alert, device, identity and incident being examined.
The move does not automatically repair every process built around the old experience. It also does not make every downstream activity free. Microsoft notes that some Sentinel indicator-matching patterns can still create ingestion cost.
Why this matters to a South African organisation
Security teams are usually judged on response time, evidence quality and containment. None of those outcomes is protected by a successful Microsoft product migration alone. The real test is whether your analysts can still find context, enrich an incident, run the expected automation and document the result without creating an unplanned data-cost spike.
This is especially important for lean teams and managed-service environments. One broken dependency can sit unnoticed until the next phishing investigation, ransomware alert or identity compromise.
What to do this week
- Inventory the dependencies. List saved links, browser bookmarks, API consumers, indicator feeds, analyst runbooks, automation rules, reports and training material that refer to the old experience.
- Map every dependency. Record where each function now lives in Defender XDR or Microsoft Sentinel. Assign a named owner for anything that does not map cleanly.
- Test one real investigation. Use a closed incident or safe test case. Confirm that an analyst can find the threat actor, review indicators, connect the context to the incident and preserve the evidence.
- Check access. Verify the roles needed by analysts, service accounts and automation. Do not assume the previous permissions carried across.
- Compare the cost pattern. Review Sentinel ingestion and matching activity against the previous baseline before expanding the new workflow.
The Braintree view
The useful question is not whether Microsoft moved the intelligence successfully. It is whether your security operation moved with it. Treat the change as a workflow migration with owners, tests and evidence. Close the gap before an incident closes it for you.
