/
/

How to Build an Incident Triage Workflow Across Multiple Microsoft 365 Tenants

by Ann Conte, IT Technical Writer
How to Build an Incident Triage Workflow Across Multiple Microsoft 365 Tenants blog banner image

Instant Summary

This NinjaOne blog post offers a comprehensive basic CMD commands list and deep dive into Windows commands with over 70 essential cmd commands for both beginners and advanced users. It explains practical command prompt commands for file management, directory navigation, network troubleshooting, disk operations, and automation with real examples to improve productivity. Whether you’re learning foundational cmd commands or mastering advanced Windows CLI tools, this guide helps you use the Command Prompt more effectively.

Key Points

  • Establish a standardized cross-tenant triage framework: Define a consistent logging structure using JSON or CSV templates to capture essential data points like tenant IDs, timestamps, and alert categories across all managed environments.
  • Centralize security alerts via API integration: Use the Microsoft Graph API to aggregate security data from multiple tenants into a single dashboard, eliminating the need for manual per-tenant checks and improving visibility.
  • Implement local endpoint tagging for tracking: Deploy PowerShell scripts to write status updates directly to the Windows Registry, allowing technicians to identify a device’s triage state and incident history without leaving their management console.
  • Categorize incidents by severity and impact: Map alerts to low, medium, or high severity levels based on business urgency and the sensitivity of the affected data to prioritize response efforts effectively.
  • Execute automated remediation workflows: Use script-based responses or conditional access policies to instantly isolate compromised devices, reset user credentials, and resolve frequent security incidents with minimal manual oversight.

Creating a comprehensive and well-defined incident triage workflow is essential for IT administrators, especially for those who manage a large number of devices. This allows IT staff to detect and contain incidents, such as security breaches, much more quickly and efficiently, and prevent personnel from experiencing alert fatigue.

Having an incident triage workflow also supports incident SLAs and ensures your organization is compliant with regulatory requirements. It will also improve reporting consistency for quarterly business reviews and legal compliance.

A step-by-step guide to creating an incident triage framework

The first step to creating an incident triage workflow is to define a set framework and create a JSON or CSV file where you can log the incidents you may encounter. You must pull up data from the Microsoft Graph API and see if there are alerts that need to be addressed.

In case an incident does happen, you can tag specific devices or users using the Windows Registry.

📌 Prerequisites:

  • This guide applies to systems with Microsoft 365 tenants with Microsoft Defender for Office 365 and/or Microsoft 365 Defender.
  • You will need to have Windows PowerShell 7 or higher installed.
  • Tenant-specific account application registrations are required. If possible, you should also have a central service account to make things more efficient.
  • You will need an RMM platform to manage your devices.
  • Optional: It would be useful to have Logic Apps or an SIEM to help automate the escalation of high-severity incidents.
  • Recommended: You can also use Microsoft Lighthouse for a free, unified view of security alerts across all delegated tenants, or Microsoft Sentinel for advanced cross-tenant SOAR (Security Orchestration, Automation, and Response) capabilities.

📌 Recommended deployment strategies:

Click to Choose a Step

💻

Best for Individual Users

💻💻💻

Best for Enterprises

Step 1: Define a cross-tenant triage framework
Step 2: Use Microsoft Graph API to pull alerts from each tenant
Step 3: Tag devices or users via Registry or PowerShell for local triage
Step 4: Automate response with PowerShell or conditional access

Step 1: Define a cross-tenant triage framework

The first thing you have to do is to standardize the core-triage phases for all your tenants when an incident occurs. Here’s a sample triage guide:

Triage PhaseAction
IngestPull the incident reports using Microsoft Graph, the Defender API, or your RMM tool.
ClasifyAssign a severity (low, medium, high), depending on what caused the alert and its effects.
CorrelateFind and link it to the affected users, devices, or accounts.
TagFlag it with the recommended action, such as escalation, resolution, or suppression.
RespondDeploy the fix or remediation using Microsoft Graph, Windows PowerShell, or your RMM tool.
ReportRecord the details of the incident and the metadata of each affected tenant.

Create a JSON template or CSV schema to log these incidents. The specific details of the template will depend on your organization’s policies and expectations.

Step 2: Use Microsoft Graph API to pull alerts from each tenant

📌 Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

  1. Open the Start Menu and search for Windows PowerShell.
  2. Right-click Windows PowerShell Run as administrator.
  3. Type this script and press Enter:

Connect-MgGraph -Scopes “SecurityEvents.Read.All”

$alerts = Get-MgSecurityAlert -All | Where-Object { $_.Status -ne “resolved” }

To filter by severity and product:

$highAADAlerts = $alerts | Where-Object { 

$_.Severity -eq “high” -and $_.ProductName -eq “Azure Active Directory Identity Protection”

$highAADAlerts | Select-Object Id, Severity, Status, ProductName, Title, CreatedDateTime}

This will pull up all the relevant alerts from Defender for your tenants, if there are any.

  1. Run these queries on a scheduled loop for all your tenants and export the results to a .CSV or .JSON file so you can track the data easily. You can do these tasks using your preferred endpoint management tool.

Step 3: Tag devices or users via Registry or PowerShell for local triage

When an incident happens on a specific endpoint, administrators can create Registry keys and values to record data regarding incidents on a specific device or user profile. This information will be saved locally. To do that, follow these steps:

  1. Open the Start Menu and search for Windows PowerShell.
  2. Right-click Windows PowerShell Run as administrator.
  3. Deploy a script that will create the necessary Registry values to track incident data on a device.

Here’s a sample PowerShell script you can use:

New-Item -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Force

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “LastAlert” -Value “PhishingAttempt”

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “Tag” -Value “UnderInvestigation”

The name and value of the registry keys (“LastAlert,” “PhishingAttempt,” “Tag,” and “UnderInvestigation”) are dependent on the incident that you’re trying to record. Change it according to your needs.

  1. To check these Registry keys and values, open Command Prompt as an administrator.
  2. Type this command and press Enter:

reg query HKLM\SOFTWARE\Org\IncidentTriage

Replace the path with the path of the value you want to check.

💡 Note: You can use an RMM tool to scan your managed devices and give a report on the tag values and track each endpoint state.

While Registry keys are useful for local RMM tracking, you should also apply Defender for Endpoint tags via the API. This ensures the “Under Investigation” status is visible to anyone looking at the Microsoft Defender Security Center.

# Example: Tagging a device in Defender for Endpoint via API

$DeviceID = “your-device-id”

$Tag = “UnderInvestigation”

Invoke-RestMethod -Uri “https://api.security.microsoft.com/api/machines/$DeviceID/tags” -Method Post -Body @{Value=$Tag;Action=”Add”}

Step 4: Automate response with PowerShell or conditional access

If there’s an incident involving a compromised user account, you can disable that account and invalidate all their user sessions. You can use Windows PowerShell to deploy specific responses for that incident. Here are a few sample actions they can take when an incident occurs:

📌 Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

  1. Open the Start Menu and search for Windows PowerShell.
  2. Right-click Windows PowerShell > Run as administrator.
  3. To disable the compromised accounts:

Update-MgUser -UserId $user.Id -AccountEnabled $false

To invalidate sessions of the compromised account:

Invoke-MgInvalidateUserRefreshToken -UserId $user.Id

To require a user to change their password:

Update-MgUser -UserId $user.Id -ForceChangePasswordNextSignIn $true

To tag a device as quarantined using a Registry tag:

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “IsolationState” -Value “Quarantined”

Please note this must be done manually on the compromised endpoint. You can’t do it remotely because the computer should be isolated from your organization’s network.

💡 Note: Administrators can use an endpoint management tool to apply Firewall rules or disable network interfaces.

Instead of manually visiting a computer to unplug it, use the Defender API to isolate the device. This cuts all network connections except for its link to Microsoft 365, preventing lateral movement.

# Isolate a device remotely

Invoke-MgIsolateSecurityMachine -MachineId $MachineId -Comment “Isolating due to high-severity alert.”

⚠️ Troubleshooting/Things to look out for

RisksPotential ConsequencesReversals
There are missing alerts.You will miss alerts regarding security breaches.Make sure that alert policy thresholds in Microsoft Defender are enabled and calibrated properly.
You are experiencing throttling with the Microsoft Graph API.Microsoft Graph API will limit your requests, meaning you will have a longer time performing all the necessary tasks during the triage.Modify your workflow to respect per-tenant call limits. You can also employ re-try logic to ensure all necessary actions are accomplished.
The Registry key is not updating.The information regarding the incidents may not be recorded.Make sure you have all the necessary permissions. You should validate the execution context as well.
The device is not responding to isolation.The issue will not be resolved and can lead to more incidents.Check if there are conflicting group policies or if it’s being blocked by an antivirus script.
Session HijackingDisabling the account doesn’t stop an attacker using a stolen token.Ensure you use the Invoke-MgInvalidateUserRefreshToken command and verify “Continuous Access Evaluation” (CAE) is active.

Additional considerations when building an incident response framework across multiple Microsoft 365 tenants

  • Use certificate-based application registrations with short expiration dates to prevent security breaches.
  • Store incident and triage logs based on tenant IDs or display names for historical audits.
  • Consider integrating Logic Apps or Power Automate to help you escalate high-severity incidents.
  • Consider third-party security tools via API when possible to give your organization more layers of protection and prevent security breaches.

Quick-Start Guide

NinjaOne can help you build an incident triage workflow across multiple Microsoft 365 tenants. Here’s how NinjaOne supports this capability:

Centralized Monitoring

  • Single Dashboard View: NinjaOne provides a unified dashboard that aggregates data from all connected Microsoft 365 tenants
  • Cross-Tenant Visibility: Monitor incidents, alerts, and security events across all tenants from one interface

Automated Triage & Response

Custom Alert Rules: Create automated triage rules that can:

  • Automatically classify incidents based on tenant, severity, or service
  • Route incidents to appropriate teams or technicians
  • Apply predefined response actions for common issues

Advanced Correlation

  • Cross-Tenant Analysis: Correlate events and alerts across multiple tenants to identify broader security patterns
  • Unified Incident View: See the complete picture of an incident that spans multiple environments

Response Coordination

  • Team Management: Assign incidents to specific teams or individuals based on tenant or service ownership
  • Escalation Paths: Define clear escalation procedures for complex cross-tenant incidents

Reporting & Compliance

  • Cross-Tenant Reporting: Generate reports that span all tenants for compliance and audit purposes
  • Standardized Processes: Implement consistent incident handling procedures across all environments

How NinjaOne services can help with your cyber-incident triage workflow

NinjaOne can support cross-tenant incident triaging by:

  • Running PowerShell scripts across specific device tags or client scopes to address the incidents
  • Logging and creating reports using incident metadata
  • Providing user-friendly dashboards and script audit logs across tenants to make creating business summaries and reviews easier

Strengthen security by building a comprehensive incident triage process

IT administrators can contain incidents like security breaches much more quickly and efficiently if they have an automated and comprehensive triage workflow. It also standardizes documentation and allows organizations to meet legal compliance obligations.

Related topics:

FAQs

The first step is defining a structured framework, typically recorded in a JSON or CSV file. This framework acts as a template for logging every incident you encounter, ensuring that your team captures consistent data—such as timestamps, affected tenants, and severity levels—across different environments.

To manage alerts at scale, you should utilize the Microsoft Graph API. By running scheduled queries, you can pull security data from all your Microsoft 365 tenants into one centralized system. This avoids the need to log into each tenant individually and allows you to correlate similar alerts across your entire client base.

The Windows Registry can be used as a local tracking mechanism for devices under investigation. By deploying PowerShell scripts to create specific registry keys (like “UnderInvestigation” or “PhishingAttempt”), technicians can see the real-time status of a device directly on the endpoint, which is especially useful when using an RMM tool for remote management.

Severity mapping ensures that your most critical resources receive immediate attention. By classifying incidents based on their effect on operations and the sensitivity of the data involved, you can prioritize high-risk alerts for immediate escalation while handling lower-risk issues through routine maintenance or automated scripts.

Once an incident is triaged and tagged, you can use PowerShell or your RMM platform to trigger automated remediation tasks. This includes actions like resetting compromised user passwords, revoking active sessions via Microsoft Graph, or running cleanup scripts on affected endpoints to contain the threat without manual intervention.

You might also like

Ready to simplify the hardest parts of IT?