Microsoft Sentinel gives organisations visibility across identity, endpoint, email, cloud, network and third-party security data—but only when the right sources are connected, analytics are tuned and investigation workflows are operational.
GEMXIT helps organisations plan, review and improve Microsoft Sentinel across SIEM architecture, Defender XDR integration, data connectors, analytics rules, KQL hunting, workbooks, automation and incident response design.
With Sentinel moving fully into the Microsoft Defender portal after 31 March 2027, now is the time to review permissions, connectors, incidents, automation and analyst workflows before the transition becomes urgent.
A service page for Microsoft Sentinel setup, Defender portal transition planning, SIEM visibility, analytics rule review, KQL workbooks and security operations.
Important Microsoft Sentinel change: Defender portal transition
Microsoft Sentinel is transitioning into the Microsoft Defender portal as part of Microsoft’s unified security operations experience. Microsoft states that after 31 March 2027, Sentinel will no longer be supported in the Azure portal and will be available only through the Microsoft Defender portal.
For Australian businesses, this is more than a portal change. It affects how security teams investigate incidents, manage permissions, review Defender XDR integration, use connectors, and maintain operational workflows.
What changesSentinel investigations increasingly move into the Defender portal, alongside Defender XDR incidents, alerts and security signals.
What to review nowConnectors, analytics rules, automation rules, playbooks, permissions, incident workflows and reporting should be checked before migration pressure builds.
Why GEMXIT caresWe focus on visibility, KQL threat hunting and practical security operations — the areas most affected when Sentinel and Defender workflows come together.
What Microsoft Sentinel adds
Microsoft Sentinel provides cloud-native SIEM and SOAR capabilities for collecting, correlating and investigating security events across Microsoft 365, Azure, Defender XDR, identity, endpoint, cloud and third-party environments.
Centralised security visibilityBring identity, endpoint, firewall, cloud and Microsoft 365 logs into one investigation plane.
Analytics rulesTurn important patterns into scheduled detections and incidents.
Workbooks and reportingVisualise trends, gaps, incidents and security posture in a way decision-makers can understand.
Defender XDR + Sentinel: why the integration matters
The strongest Microsoft security environments do not treat Sentinel, Defender, Entra ID and Microsoft 365 logs as separate islands. They bring the signals together so incidents can be understood faster and with better context.
Unified incidentsReview how Defender XDR incidents, Sentinel incidents, alerts and entities are being grouped and investigated.
Security operations designDesign the process around how analysts actually investigate identity, email, endpoint and cloud activity.
Practical KQL example: after-hours activity
Not every incident starts with malware. Sometimes the first signal is activity happening at a time that does not match normal business behaviour.
sentinel-after-hours-activity.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SigninLogs
| where TimeGenerated > ago(14d)
| extend HourOfDay = datetime_part("hour", TimeGenerated)
| where HourOfDay < 6 or HourOfDay > 20
| project
TimeGenerated,
UserPrincipalName,
IPAddress,
Location,
AppDisplayName,
ResultType,
ConditionalAccessStatus
| order by TimeGenerated desc
How to read this query
TimeGenerated > ago(14d) limits the hunt to recent sign-in behaviour.
HourOfDay < 6 or HourOfDay > 20 highlights activity outside normal business hours.
Location, IPAddress and AppDisplayName help determine whether the activity matches the user's normal pattern.
ConditionalAccessStatus helps show whether the sign-in was challenged, blocked, allowed or not evaluated.
Used forFinding sign-ins that may be legitimate but deserve review because of timing.
Best pivotCompare location, device, application, conditional access and user history.
Why it mattersGood detection often starts with behaviour, not malware signatures.
Real-world Sentinel findings
A Sentinel environment can look healthy from a distance while still missing the data, detections or workflows needed for real investigations.
Important logs are missingIdentity, endpoint, firewall, cloud or Microsoft 365 logs may not be connected, leaving investigations incomplete.
Rules are noisy or too quietAnalytics rules may generate too many low-value incidents, or they may miss the behaviour the business actually cares about.
Workbooks do not answer useful questionsDashboards often show activity, but not enough context to help a manager, analyst or administrator decide what to do next.
What a Sentinel review should include
The goal is not just to confirm Sentinel is deployed. The goal is to confirm it can support real detection, triage, investigation and reporting.
Connector and table reviewConfirm which data sources are connected, which tables are populated, and which important signals are still missing.
Response workflow readinessCheck whether incidents have owners, triage notes, escalation paths, automation, and a clear investigation process.
Sentinel setup areas GEMXIT can review
Sentinel value depends on the right data connectors, analytics rules, workbooks, retention and response process.
Data connectorsValidate which logs are connected and whether important sources are missing.
Rules and incidentsReview analytics coverage, noisy detections and practical incident workflow.
SOC-style visibilityBuild workbooks and dashboards that make security posture easier to understand.
Sentinel to Defender portal readiness review
A good Sentinel review should not only ask “is Sentinel turned on?” It should ask whether the environment is ready for the way Microsoft security operations are moving.
Portal transitionReview current Azure portal Sentinel usage and identify what needs to move into the Defender portal workflow.
Permissions and rolesCheck whether current Azure permissions, Sentinel roles and Defender portal access still support the way your team works.
Automation and reportingReview automation rules, Logic Apps, workbook assumptions and reporting processes before the operational model changes.
Continue learning with Agent Foskett
Move from Sentinel service guidance into structured Academy lessons, practical SOC workflows and copy-ready KQL investigations.
Microsoft Sentinel Academy
Follow a structured learning path covering Sentinel architecture,
Log Analytics workspaces, data connectors, analytics rules, incidents,
entities, workbooks, automation, threat hunting, KQL, Defender XDR
integration and operational SOC workflows.
Sentinel foundationsLearn workspaces, connectors, tables, incidents, entities, analytics rules and the architecture behind cloud-native SIEM operations.
KQL threat huntingBuild practical queries across identity, endpoint, email, Azure and security alert data to investigate behaviour rather than isolated events.
Operational SOC workflowsConnect triage, entity investigation, workbooks, automation, playbooks and response ownership into repeatable Sentinel operations.
Defender XDR integrationUnderstand unified incidents, connector behaviour, duplicated alerts, shared entities and investigation flow across Defender and Sentinel.
Workbooks and visibilityCreate useful operational views for sign-ins, incidents, Defender activity, trends, coverage gaps and management reporting.
Security Copilot assistanceUse Microsoft Security Copilot to summarise incidents, explain KQL, organise evidence and suggest next steps while analysts verify source data.
Frequently asked questions
Microsoft Sentinel becomes more valuable when the business understands what it collects, what it detects, and how analysts should respond.
What is Microsoft Sentinel?Microsoft Sentinel is a cloud-native SIEM and SOAR platform used to collect, correlate, detect and investigate security activity across cloud and on-premises environments.
Is Sentinel replacing Defender XDR?No. Sentinel and Defender XDR work together. Defender provides deep Microsoft security signal, while Sentinel supports broader SIEM, KQL analytics, automation and reporting.
Why does KQL matter in Sentinel?KQL is the query language used to search logs, build analytics rules, investigate incidents and create useful Sentinel workbooks.
Do we need to prepare for the Defender portal?Yes. Organisations should review permissions, connectors, incidents, automation, workbooks and analyst workflows before relying fully on the Defender portal experience.
Can GEMXIT build Sentinel workbooks?Yes. GEMXIT can help design practical workbooks that show identity, Defender, sign-in, incident and security posture information clearly.
Can Security Copilot assist Sentinel investigations?Yes. Security Copilot can help summarise incidents, explain KQL, organise evidence and identify investigation pivots, while analysts validate the underlying logs and conclusions.
How often should Sentinel be reviewed?At least annually, and whenever major connectors, licensing, portal changes, retention settings or security operations workflows affect how the team investigates threats.
Related Microsoft security pages
Sentinel is strongest when it is connected to identity, Defender, Zero Trust and real investigation capability.
Sentinel works best when it is part of a broader Microsoft security strategy. These GEMXIT resources help connect the dots between KQL, Defender, identity and real-world threat hunting.
Want to know whether Microsoft Sentinel is ready for real security operations? GEMXIT can review connectors, analytics rules, incidents, KQL visibility, workbooks, automation and Defender portal readiness, then turn the findings into a practical improvement roadmap.