đź“‹ Microsoft Entra Documentation Changes

Daily summary for changes since May 11th 2026, 10:55 PM PDT

Report generated on May 12th 2026, 10:55 PM PDT

đź“Š Summary

18
Total Commits
0
New Files
15
Modified Files
0
Deleted Files
7
Contributors

đź“ť Modified Documentation Files

MODIFIED docs/global-secure-access/how-to-operate-microsoft-traffic.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+24 / -22 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
## Alerting and monitoring
 
This section is organized in the order you should implement monitoring for Microsoft traffic: 1. Review the critical alerts and the required operator response.
2. Use the Kusto Query Language (KQL) queries to create the detections.
3. Follow the automation steps to enable Sentinel-driven notification and response workflows.
 
> [!IMPORTANT]
> In the first 30 days after deployment, use the [Microsoft traffic volume—daily trend](#kql-queries---non-critical) query to establish a normal traffic baseline before finalizing alert thresholds. The 50-user CA failure threshold in the Conditional Access failure KQL query is a starting point—calibrate it to your organization's actual sign-in volume.
 
| Alert | Condition | Role | What to do next |
| --- | --- | --- | --- |
| Conditional Access policy failure for Microsoft traffic | Conditional Access policy applied to Microsoft traffic is blocking more users than expected | Identity Engineer / Identity Team | 1. Review the Conditional Access policy evaluation in Entra sign-in logs. 2. Check if a recent policy change is causing overblocking. 3. Validate device compliance status for affected users. |
| Audit log: traffic forwarding rule change | A traffic forwarding rule for Microsoft traffic is modified | Network Security Engineer | 1. Verify the change was approved through change management. 2. Confirm the modified rule still includes all required Microsoft 365 service endpoints. 3. Monitor for user-reported issues after the change. |
| Microsoft traffic profile disabled | The Microsoft traffic forwarding profile is disabled | Network Security Engineer | Microsoft 365 traffic is no longer routed through GSA. 1. Re-enable the profile in **Global Secure Access** > **Connect** > **Traffic forwarding**. 2. Check audit logs to identify who disabled it. 3. Verify Microsoft 365 connectivity is restored for users. |
| Conditional Access Signaling disabled | The CA Signaling setting in Global Secure Access is turned off, preventing GSA from providing network location signals to Conditional Access | Identity Engineer / Identity Team | Compliant network Conditional Access policies stop enforcing. 1. Re-enable CA Signaling in **Global Secure Access** > **Settings** > **Session management** > **Adaptive access**. 2. Check audit logs to identify who disabled it. 3. Verify compliant network location signals are appearing in sign-in logs before closing the incident. |
| Universal Tenant Restrictions disabled | The Universal Tenant Restrictions policy is turned off | Identity Engineer / Identity Team | **This is only applicable for organizations using Tenant Restrictions.** External tenant access controls are no longer enforced—users may be able to sign into unauthorized external tenants. 1. Re-enable Universal Tenant Restrictions in **Global Secure Access** > **Settings** > **Session management** > **Universal tenant restrictions**. 2. Check audit logs to identify who disabled it. 3. Review sign-in logs for any external tenant sign-ins that occurred during the gap. |
 
 
> [!TIP]
 
## Alerting and monitoring
 
This section is organized in the order you should implement monitoring for Microsoft traffic:
 
1. Review the critical alerts and the required operator response.
1. Use the Kusto Query Language (KQL) queries to create the detections.
1. Follow the automation steps to enable Sentinel-driven notification and response workflows.
 
> [!IMPORTANT]
> In the first 30 days after deployment, use the [Microsoft traffic volume—daily trend](#kql-queries---non-critical) query to establish a normal traffic baseline before finalizing alert thresholds. The 50-user CA failure threshold in the Conditional Access failure KQL query is a starting point—calibrate it to your organization's actual sign-in volume.
 
| Alert | Condition | Role | What to do next |
| --- | --- | --- | --- |
| Conditional Access policy failure for Microsoft traffic | Conditional Access policy applied to Microsoft traffic is blocking more users than expected | Identity Engineer / Identity Team | 1. Review the Conditional Access policy evaluation in Microsoft Entra sign-in logs.<br>2. Check if a recent policy change is causing overblocking.<br>3. Validate device compliance status for affected users. |
| Audit log: traffic forwarding rule change | A traffic forwarding rule for Microsoft traffic is modified | Network Security Engineer | 1. Verify the change was approved through change management.<br>2. Confirm the modified rule still includes all required Microsoft 365 service endpoints.<br>3. Monitor for user-reported issues after the change. |
| Microsoft traffic profile disabled | The Microsoft traffic forwarding profile is disabled | Network Security Engineer | Microsoft 365 traffic is no longer routed through GSA.<br>1. Re-enable the profile in **Global Secure Access** > **Connect** > **Traffic forwarding**.<br>2. Check audit logs to identify who disabled it.<br>3. Verify Microsoft 365 connectivity is restored for users. |
| Conditional Access Signaling disabled | The CA Signaling setting in Global Secure Access is turned off, preventing GSA from providing network location signals to Conditional Access | Identity Engineer / Identity Team | Compliant network Conditional Access policies stop enforcing.<br>1. Re-enable CA Signaling in **Global Secure Access** > **Settings** > **Session management** > **Adaptive access**.<br>2. Check audit logs to identify who disabled it.<br>3. Verify compliant network location signals are appearing in sign-in logs before closing the incident. |
| Universal Tenant Restrictions disabled | The Universal Tenant Restrictions policy is turned off | Identity Engineer / Identity Team | **This is only applicable for organizations using Tenant Restrictions.** External tenant access controls are no longer enforced—users may be able to sign into unauthorized external tenants.<br>1. Re-enable Universal Tenant Restrictions in **Global Secure Access** > **Settings** > **Session management** > **Universal tenant restrictions**.<br>2. Check audit logs to identify who disabled it.<br>3. Review sign-in logs for any external tenant sign-ins that occurred during the gap. |
 
MODIFIED docs/global-secure-access/reference-change-request-template.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+19 / -19 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
## Scope and impact
 
**Affected Global Secure Access capability:**
- [ ] Private Access
- [ ] Internet Access
- [ ] Remote Networks
- [ ] Microsoft Traffic
- [ ] Common / Cross-cutting
 
**Affected components:**
 
 
**Expected user impact during change:**
 
- [ ] No user impact
- [ ] Brief reconnection (< 1 minute)
- [ ] Service interruption during maintenance window
- [ ] Extended impact—communication plan required
 
## Risk assessment
## Scope and impact
 
**Affected Global Secure Access capability:**
- Private Access
- Internet Access
- Remote Networks
- Microsoft Traffic
- Common / Cross-cutting
 
**Affected components:**
 
 
**Expected user impact during change:**
 
- No user impact
- Brief reconnection (< 1 minute)
- Service interruption during maintenance window
- Extended impact—communication plan required
 
## Risk assessment
MODIFIED docs/global-secure-access/how-to-operate-private-access.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+15 / -17 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
---
title: Operate Microsoft Entra Private Access
description: "Post-deployment operations guide for Microsoft Entra Private Access, the zero trust network access (ZTNA) capability, covering alerting, health checks, integration, automation, and operational metrics."
ms.topic: how-to
ms.date: 05/04/2026
ms.reviewer: plenzke
 
| Alert | Condition | Role | Automated by | What to do next |
| --- | --- | --- | --- | --- |
| Connector offline | A Private Access connector stops sending heartbeats for more than 5 minutes | Network Ops L1 | Sentinel analytics rule *Connector health degradation* (content hub) | 1. Check the connector server: verify the `Microsoft Entra private network connector` Windows service is running. 2. Check outbound connectivity to `*.msappproxy.net` on port 443. 3. Review Windows Event Logs on the connector host. 4. If the connector can't be recovered, verify traffic has failed over to another connector in the group (see [Failover validation](#failover-validation)). See [Microsoft Entra private network connectors](/entra/global-secure-access/concept-connectors#maintenance) and [Troubleshoot problems installing the private network connector](/entra/global-secure-access/troubleshoot-connectors#troubleshooting-connector-functionality). |
| All connectors in a group offline | No connectors in a connector group are sending heartbeats | Network Ops L2 + Incident Commander | Sentinel analytics rule *Connector group offline* + [Playbook 2](#playbook-2-auto-create-itsm-ticket-for-connector-group-failure) | **Severity: Critical.** All users of applications assigned to this group lose access. 1. Escalate immediately per your incident management process. 2. Check for common root cause: network outage, firewall change, or server patching affecting all connector hosts. 3. If recovery isn't immediate, activate your fallback connectivity plan (for example, temporary VPN access). |
| Connector high resource usage | CPU > 80% or memory > 85% sustained for 15+ minutes on a connector host | Network Ops L1 | Azure Monitor alert ([Playbook 5](#playbook-5-connector-group-capacity-alert)) | 1. Check the number of active sessions on the connector. 2. Redistribute load by adding another connector to the group. 3. Investigate if a specific application is generating unusual traffic volume. |
| Application segment unreachable | Users receive connection failures for a specific Private Access application | Network Ops L1 → App Owner | Sentinel analytics rule *Private access segment failures* | 1. Verify the backend application server is running and reachable from the connector host. 2. Test DNS resolution from the connector host for the application fully qualified domain name (FQDN). 3. Check the application segment configuration in the Entra admin center for correct IP/FQDN and port ranges. See [Troubleshoot application access](/entra/global-secure-access/troubleshoot-app-access#how-does-dns-work-with-global-secure-access) and [Troubleshoot problems installing the private network connector](/entra/global-secure-access/troubleshoot-connectors#troubleshooting-connector-functionality). |
| Unusual access denials spike | Access denial count for Private Access applications increases by more than 50% compared to the seven-day baseline | Identity and access management (IAM) Ops + SOC | Sentinel scheduled analytics rule *Unusual private access denials* (derived from the top-denied-apps Kusto Query Language (KQL) query) | 1. Review `NetworkAccessTraffic` for the denied sessions—identify the users, apps, and denial reasons. 2. Determine whether this denial pattern is a policy misconfiguration (legitimate users blocked) or a security event (unauthorized access attempts). 3. For policy issues, adjust the Conditional Access or app assignment. For security events, escalate to your SOC. |
| Unauthorized configuration change | A Private Access configuration change is made by an unexpected identity or without a matching change ticket | SOC + IAM Admin | [Playbook 8: Private Access configuration change alert](#playbook-8-private-access-configuration-change-alert) | 1. Identify the actor and change details in Entra audit logs. 2. Verify whether the change was approved through your change management process. 3. If unauthorized, revert the change and investigate the identity compromise. See [How to access the Global Secure Access audit logs](/entra/global-secure-access/how-to-access-audit-logs#overview), [Microsoft Entra audit log categories and activities](/entra/identity/monitoring-health/reference-audit-activities#global-secure-access), and [Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
 
> [!TIP]
> Use [Microsoft Security Copilot](/security-copilot/) to investigate alert context. Security Copilot can correlate Private Access connection failures with identity risk signals and summarize cross-data findings. For example, prompt: *"Summarize the risk context for users with denied Private Access connections and elevated identity risk in the last 24 hours."*
 
**Connector health—identify offline connectors:**
---
title: Operate Microsoft Entra Private Access
description: "Post-deployment operations guide for Microsoft Entra Private Access, the Zero Trust network access (ZTNA) capability, covering alerting, health checks, integration, automation, and operational metrics."
ms.topic: how-to
ms.date: 05/04/2026
ms.reviewer: plenzke
 
| Alert | Condition | Role | Automated by | What to do next |
| --- | --- | --- | --- | --- |
| Connector offline | A Private Access connector stops sending heartbeats for more than 5 minutes | Network Ops L1 | Sentinel analytics rule *Connector health degradation* (content hub) | 1. Check the connector server: verify the `Microsoft Entra private network connector` Windows service is running.<br>2. Check outbound connectivity to `*.msappproxy.net` on port 443.<br>3. Review Windows Event Logs on the connector host.<br>4. If the connector can't be recovered, verify traffic has failed over to another connector in the group (see [Failover validation](#failover-validation)). See [Microsoft Entra private network connectors](/entra/global-secure-access/concept-connectors#maintenance) and [Troubleshoot problems installing the private network connector](/entra/global-secure-access/troubleshoot-connectors#troubleshooting-connector-functionality). |
| All connectors in a group offline | No connectors in a connector group are sending heartbeats | Network Ops L2 + Incident Commander | Sentinel analytics rule *Connector group offline* + [Playbook 2](#playbook-2-auto-create-itsm-ticket-for-connector-group-failure) | **Severity: Critical.** All users of applications assigned to this group lose access.<br>1. Escalate immediately per your incident management process.<br>2. Check for common root cause: network outage, firewall change, or server patching affecting all connector hosts.<br>3. If recovery isn't immediate, activate your fallback connectivity plan (for example, temporary VPN access). |
| Connector high resource usage | CPU > 80% or memory > 85% sustained for 15+ minutes on a connector host | Network Ops L1 | Azure Monitor alert ([Playbook 5](#playbook-5-connector-group-capacity-alert)) | 1. Check the number of active sessions on the connector.<br>2. Redistribute load by adding another connector to the group.<br>3. Investigate if a specific application is generating unusual traffic volume. |
| Application segment unreachable | Users receive connection failures for a specific Private Access application | Network Ops L1 → App Owner | Sentinel analytics rule *Private access segment failures* | 1. Verify the backend application server is running and reachable from the connector host.<br>2. Test DNS resolution from the connector host for the application fully qualified domain name (FQDN).<br>3. Check the application segment configuration in the Microsoft Entra admin center for correct IP/FQDN and port ranges. See [Troubleshoot application access](/entra/global-secure-access/troubleshoot-app-access#how-does-dns-work-with-global-secure-access) and [Troubleshoot problems installing the private network connector](/entra/global-secure-access/troubleshoot-connectors#troubleshooting-connector-functionality). |
| Unusual access denials spike | Access denial count for Private Access applications increases by more than 50% compared to the seven-day baseline | Identity and access management (IAM) Ops + SOC | Sentinel scheduled analytics rule *Unusual private access denials* (derived from the top-denied-apps Kusto Query Language (KQL) query) | 1. Review `NetworkAccessTraffic` for the denied sessions—identify the users, apps, and denial reasons.<br>2. Determine whether this denial pattern is a policy misconfiguration (legitimate users blocked) or a security event (unauthorized access attempts).<br>3. For policy issues, adjust the Conditional Access or app assignment. For security events, escalate to your SOC. |
| Unauthorized configuration change | A Private Access configuration change is made by an unexpected identity or without a matching change ticket | SOC + IAM Admin | [Playbook 8: Private Access configuration change alert](#playbook-8-private-access-configuration-change-alert) | 1. Identify the actor and change details in Microsoft Entra audit logs.<br>2. Verify whether the change was approved through your change management process.<br>3. If unauthorized, revert the change and investigate the identity compromise. See [How to access the Global Secure Access audit logs](/entra/global-secure-access/how-to-access-audit-logs#overview), [Microsoft Entra audit log categories and activities](/entra/identity/monitoring-health/reference-audit-activities#global-secure-access), and [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
 
> [!TIP]
> Use [Microsoft Security Copilot](/security-copilot/) to investigate alert context. Security Copilot can correlate Private Access connection failures with identity risk signals and summarize cross-data findings. For example, prompt: *"Summarize the risk context for users with denied Private Access connections and elevated identity risk in the last 24 hours."*
 
**Connector health—identify offline connectors:**
MODIFIED docs/global-secure-access/how-to-operate-internet-access.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+14 / -14 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
| Alert | Condition | Role | Automated by | What to do next |
| --- | --- | --- | --- | --- |
| Web filtering policy bypass | Traffic matching a blocked category is allowed due to a policy misconfiguration or override | Identity and access management (IAM) Admin | Sentinel analytics rule *Web filtering anomaly detection* (content hub) | 1. Review the policy rule order in the Entra admin center. 2. Check for user or group exceptions that may be overriding the block. 3. Correct the policy and test from an affected user device. |
| Traffic forwarding profile disabled | The Internet Access traffic forwarding profile is disabled or removed | Network Ops L2 + Incident Commander | Sentinel scheduled analytics rule on `AuditLogs` for `Update forwarding profile` + [Playbook 8](#playbook-8-internet-access-configuration-change-alert) | **Severity: Critical.** Users' internet traffic is no longer routed through Global Secure Access. 1. Re-enable the profile in **Global Secure Access** > **Connect** > **Traffic forwarding**. 2. Check audit logs to identify who disabled it and whether it was an approved change. |
| TLS inspection failure spike | TLS inspection failures increase by more than 30% compared to the seven-day baseline | Network Ops L2 | Sentinel analytics rule *TLS inspection failure spike* + Zero Trust (ZT) Assessment *TLS inspection failure rate is below 1%* | 1. Check if a major SaaS provider changed their certificate pinning. 2. Review the TLS inspection bypass list for applications that require exemption. 3. Update the bypass list and monitor for resolution. |
| Unusual outbound data transfer | A single user or device transfers more than 500-MB outbound in a 1-hour window (adjust to your baseline) | SOC | Sentinel analytics rule *Unusual outbound data transfer* | 1. Identify the user and destination in `NetworkAccessTraffic`. 2. Determine whether the activity is a legitimate bulk upload or potential data exfiltration. 3. If suspicious, escalate to your SOC. See [Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
| High volume of blocked URL requests | A single user generates more than 100 blocked URL requests in 1 hour | SOC → Endpoint Admin | Sentinel scheduled analytics rule on `NetworkAccessTraffic` (denied count per user) | 1. Review whether the traffic represents malware on the device (automated callbacks) or user behavior. 2. If malware-related, escalate to endpoint management. 3. If user behavior, consider user education or policy adjustment. |
| Web category reclassification impact | After a Microsoft URL category database update, legitimate business sites are newly blocked | IAM Admin → App Owner | [Playbook 9: Weekly policy-efficacy digest](#playbook-9-weekly-policy-efficacy-digest) (surfaces newly blocked top destinations) | 1. Review the newly blocked URLs in traffic logs. 2. Add legitimate sites to a custom allow list. 3. Open a categorization review request with Microsoft if the classification is incorrect. |
| Unauthorized configuration change | An Internet Access configuration change is made by an unexpected identity or without a matching change ticket | SOC + IAM Admin | [Playbook 8: Internet Access configuration change alert](#playbook-8-internet-access-configuration-change-alert) | 1. Identify the actor and change details in Entra audit logs. 2. Verify whether the change was approved through your change management process. 3. If unauthorized, revert the change and investigate the identity compromise. See [Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
 
> [!TIP]
> Use [Microsoft Security Copilot](/security-copilot/) to analyze patterns in blocked traffic and correlate with threat intelligence feeds.
**Prompt injection detections—sessions matched by your prompt-protection policy:**
 
> [!NOTE]
> Replace `<your-prompt-policy-name>` with the **PolicyName** of your prompt-protection policy (Entra admin center > **Global Secure Access** > **Secure** > **Prompt policies**). The `NetworkAccessTraffic` schema doesn't expose a dedicated *PromptInjectionDetected* column—detections surface as sessions evaluated by the prompt policy. Use the **Generative AI Insights logs** blade for the verdict per prompt.
 
```kusto
NetworkAccessTraffic
 
| Alert | Condition | Role | Automated by | What to do next |
| --- | --- | --- | --- | --- |
| Web filtering policy bypass | Traffic matching a blocked category is allowed due to a policy misconfiguration or override | Identity and access management (IAM) Admin | Sentinel analytics rule *Web filtering anomaly detection* (content hub) | 1. Review the policy rule order in the Microsoft Entra admin center.<br>2. Check for user or group exceptions that may be overriding the block.<br>3. Correct the policy and test from an affected user device. |
| Traffic forwarding profile disabled | The Internet Access traffic forwarding profile is disabled or removed | Network Ops L2 + Incident Commander | Sentinel scheduled analytics rule on `AuditLogs` for `Update forwarding profile` + [Playbook 8](#playbook-8-internet-access-configuration-change-alert) | **Severity: Critical.** Users' internet traffic is no longer routed through Global Secure Access.<br>1. Re-enable the profile in **Global Secure Access** > **Connect** > **Traffic forwarding**.<br>2. Check audit logs to identify who disabled it and whether it was an approved change. |
| TLS inspection failure spike | TLS inspection failures increase by more than 30% compared to the seven-day baseline | Network Ops L2 | Sentinel analytics rule *TLS inspection failure spike* + Zero Trust (ZT) Assessment *TLS inspection failure rate is below 1%* | 1. Check if a major SaaS provider changed their certificate pinning.<br>2. Review the TLS inspection bypass list for applications that require exemption.<br>3. Update the bypass list and monitor for resolution. |
| Unusual outbound data transfer | A single user or device transfers more than 500-MB outbound in a 1-hour window (adjust to your baseline) | SOC | Sentinel analytics rule *Unusual outbound data transfer* | 1. Identify the user and destination in `NetworkAccessTraffic`.<br>2. Determine whether the activity is a legitimate bulk upload or potential data exfiltration.<br>3. If suspicious, escalate to your SOC. See [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
| High volume of blocked URL requests | A single user generates more than 100 blocked URL requests in 1 hour | SOC → Endpoint Admin | Sentinel scheduled analytics rule on `NetworkAccessTraffic` (denied count per user) | 1. Review whether the traffic represents malware on the device (automated callbacks) or user behavior.<br>2. If malware-related, escalate to endpoint management.<br>3. If user behavior, consider user education or policy adjustment. |
| Web category reclassification impact | After a Microsoft URL category database update, legitimate business sites are newly blocked | IAM Admin → App Owner | [Playbook 9: Weekly policy-efficacy digest](#playbook-9-weekly-policy-efficacy-digest) (surfaces newly blocked top destinations) | 1. Review the newly blocked URLs in traffic logs.<br>2. Add legitimate sites to a custom allow list.<br>3. Open a categorization review request with Microsoft if the classification is incorrect. |
| Unauthorized configuration change | An Internet Access configuration change is made by an unexpected identity or without a matching change ticket | SOC + IAM Admin | [Playbook 8: Internet Access configuration change alert](#playbook-8-internet-access-configuration-change-alert) | 1. Identify the actor and change details in Microsoft Entra audit logs.<br>2. Verify whether the change was approved through your change management process.<br>3. If unauthorized, revert the change and investigate the identity compromise. See [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
 
> [!TIP]
> Use [Microsoft Security Copilot](/security-copilot/) to analyze patterns in blocked traffic and correlate with threat intelligence feeds.
**Prompt injection detections—sessions matched by your prompt-protection policy:**
 
> [!NOTE]
> Replace `<your-prompt-policy-name>` with the **PolicyName** of your prompt-protection policy (Microsoft Entra admin center > **Global Secure Access** > **Secure** > **Prompt policies**). The `NetworkAccessTraffic` schema doesn't expose a dedicated *PromptInjectionDetected* column—detections surface as sessions evaluated by the prompt policy. Use the **Generative AI Insights logs** blade for the verdict per prompt.
 
```kusto
NetworkAccessTraffic
MODIFIED docs/global-secure-access/how-to-operations-common.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+14 / -14 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
- [Remote Networks operations](how-to-operate-remote-networks.md)
- [Microsoft Traffic operations](how-to-operate-microsoft-traffic.md)
 
For initial deployment and configuration, see the [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro). For identity-layer security investigations and incident response, see the [Entra Security Operations Guide](https://aka.ms/AzureADSecOps).
 
## Roles and responsibilities
 
| --- | --- |
| **Service Owner / GSA Administrator** | Overall accountability for GSA performance, compliance, and alignment with business requirements. Approves significant changes. Coordinates across identity, endpoint, and networking teams. |
| **Network Security Engineer** | Day-to-day administration: access policies, routing rules, connector/tunnel management, certificate management. Tests changes before production deployment. Escalation point for complex IT Support/Help desk issues. |
| **Identity Engineer / Identity Team** | Owns the Microsoft Entra ID tenant as it intersects with GSA. Manages Conditional Access policies that gate GSA traffic profiles and compliant-network enforcement. Administers GSA service principals and enterprise app registrations (CRUD). Troubleshoots authentication, token, and sign-in failures using Entra sign-in logs. Partners with SOC Analyst on identity-related incidents. |
| **SOC Analyst** | Monitors security alerts. Investigates suspicious events. Fine-tunes analytics rules in Sentinel. Handles or escalates GSA-related security incidents. For detailed SecOps procedures, see the [Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
| **IT Support / Help desk** | Tier-1 support for user access issues (client installation, connectivity problems). Follows runbooks and escalates to Network Security Engineer for complex issues. |
| **Platform Ops / Monitoring Engineer** | Oversees infrastructure health: dashboards, connector/tunnel uptime, automation scripts, and configuration backup processes. |
 
- **GSA-specific Graph resources**: connector groups, traffic forwarding profiles, remote networks, and filtering policies.
- **Surrounding Microsoft Entra ID objects** that gate and support GSA: Conditional Access policies, named locations, service principals, and app role assignments.
 
Use two complementary mechanisms: **Graph API JSON exports** for GSA-specific resources and long-term retention, and the **Microsoft Entra Backup and Recovery APIs** for tenant-wide Entra ID objects and scoped restore.
 
- [Remote Networks operations](how-to-operate-remote-networks.md)
- [Microsoft Traffic operations](how-to-operate-microsoft-traffic.md)
 
For initial deployment and configuration, see the [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro). For identity-layer security investigations and incident response, see the [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps).
 
## Roles and responsibilities
 
| --- | --- |
| **Service Owner / GSA Administrator** | Overall accountability for GSA performance, compliance, and alignment with business requirements. Approves significant changes. Coordinates across identity, endpoint, and networking teams. |
| **Network Security Engineer** | Day-to-day administration: access policies, routing rules, connector/tunnel management, certificate management. Tests changes before production deployment. Escalation point for complex IT Support/Help desk issues. |
| **Identity Engineer / Identity Team** | Owns the Microsoft Entra ID tenant as it intersects with GSA. Manages Conditional Access policies that gate GSA traffic profiles and compliant-network enforcement. Administers GSA service principals and enterprise app registrations (CRUD). Troubleshoots authentication, token, and sign-in failures using Microsoft Entra sign-in logs. Partners with SOC Analyst on identity-related incidents. |
| **SOC Analyst** | Monitors security alerts. Investigates suspicious events. Fine-tunes analytics rules in Sentinel. Handles or escalates GSA-related security incidents. For detailed SecOps procedures, see the [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps). |
| **IT Support / Help desk** | Tier-1 support for user access issues (client installation, connectivity problems). Follows runbooks and escalates to Network Security Engineer for complex issues. |
| **Platform Ops / Monitoring Engineer** | Oversees infrastructure health: dashboards, connector/tunnel uptime, automation scripts, and configuration backup processes. |
 
- **GSA-specific Graph resources**: connector groups, traffic forwarding profiles, remote networks, and filtering policies.
- **Surrounding Microsoft Entra ID objects** that gate and support GSA: Conditional Access policies, named locations, service principals, and app role assignments.
 
Use two complementary mechanisms: **Graph API JSON exports** for GSA-specific resources and long-term retention, and the **Microsoft Entra Backup and Recovery APIs** for tenant-wide Microsoft Entra ID objects and scoped restore.
 
MODIFIED docs/global-secure-access/how-to-operate-remote-networks.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+13 / -13 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
| Alert | Condition | Role | What to do next |
| --- | --- | --- | --- |
| Tunnel down | A GRE or IPsec tunnel disconnected for more than 5 minutes | Network Security Engineer | 1. Check the on-premises CPE (Customer Premises Equipment) device status. 2. Verify the public IP and tunnel configuration didn't change. 3. Check internet service provider (ISP) connectivity at the branch. 4. If using redundant tunnels, verify traffic failed over. |
| All tunnels for a site down | No active tunnels remain for a remote network location | Network Security Engineer | **Severity: Critical.** All users at the site lose GSA-secured connectivity. 1. Escalate immediately. 2. Check for site-wide network outage. 3. Activate fallback plan (direct internet egress or backup VPN). |
| Tunnel flapping | A tunnel goes up and down more than three times in 1 hour | Network Security Engineer | 1. Check the CPE device logs for IKE/IPsec negotiation errors. 2. Verify the tunnel keepalive and Dead Peer Detection (DPD) settings. 3. Check for ISP instability or MTU issues. 4. If flapping persists, engage your network provider. |
| Tunnel bandwidth near capacity | Sustained throughput exceeds 80% of the tunnel's provisioned bandwidth for 30+ minutes | Platform Ops / Monitoring Engineer | 1. Review top traffic consumers at the site using KQL queries. 2. Determine if the traffic is legitimate growth or an anomaly. 3. Plan to add a second tunnel or upgrade bandwidth. |
| Border Gateway Protocol (BGP) session down (if applicable) | BGP peering session with GSA drops | Network Security Engineer | 1. Check BGP configuration on the CPE device. 2. Verify the peer IP and Autonomous System Number (ASN) settings. 3. Review route advertisements for changes. |
| Tunnel MTU-related packet drops | High rate of fragmented or dropped packets on the tunnel | Network Security Engineer | 1. Reduce the tunnel MTU on the CPE device (recommended: 1,400 bytes for GRE, 1,380 for IPsec). 2. Enable Transmission Control Protocol (TCP) Maximum Segment Size (MSS) clamping if not already configured. |
 
### KQL queries for remote network monitoring
 
 
| Check | Role | Procedure | What to do if it fails |
| --- | --- | --- | --- |
| Tunnel status | Platform Ops / Monitoring Engineer | Entra admin center > **Global Secure Access** > **Connect** > **Remote networks**. Verify all tunnels show **Connected**. | Check CPE device status and ISP connectivity at the affected site. |
| High-severity alerts | SOC Analyst | Review Sentinel or your security information and event management (SIEM) platform for P1/P2 remote network alerts. | Ensure each alert is assigned. Escalate unassigned alerts older than 4 hours. |
| Site traffic volume | Platform Ops / Monitoring Engineer | Spot-check traffic volumes for your largest sites against the baseline. | Investigate significant drops (possible outage) or spikes (possible anomaly). |
 
| Tunnel redundancy validation | Network Security Engineer | For sites with redundant tunnels, verify failover works. See [Tunnel failover testing](#tunnel-failover-testing). | Investigate and resolve failover issues before the next maintenance window. |
 
| Alert | Condition | Role | What to do next |
| --- | --- | --- | --- |
| Tunnel down | A GRE or IPsec tunnel disconnected for more than 5 minutes | Network Security Engineer | 1. Check the on-premises CPE (Customer Premises Equipment) device status.<br>2. Verify the public IP and tunnel configuration didn't change.<br>3. Check internet service provider (ISP) connectivity at the branch.<br>4. If using redundant tunnels, verify traffic failed over. |
| All tunnels for a site down | No active tunnels remain for a remote network location | Network Security Engineer | **Severity: Critical.** All users at the site lose GSA-secured connectivity.<br>1. Escalate immediately.<br>2. Check for site-wide network outage.<br>3. Activate fallback plan (direct internet egress or backup VPN). |
| Tunnel flapping | A tunnel goes up and down more than three times in 1 hour | Network Security Engineer | 1. Check the CPE device logs for IKE/IPsec negotiation errors.<br>2. Verify the tunnel keepalive and Dead Peer Detection (DPD) settings.<br>3. Check for ISP instability or MTU issues.<br>4. If flapping persists, engage your network provider. |
| Tunnel bandwidth near capacity | Sustained throughput exceeds 80% of the tunnel's provisioned bandwidth for 30+ minutes | Platform Ops / Monitoring Engineer | 1. Review top traffic consumers at the site using KQL queries.<br>2. Determine if the traffic is legitimate growth or an anomaly.<br>3. Plan to add a second tunnel or upgrade bandwidth. |
| Border Gateway Protocol (BGP) session down (if applicable) | BGP peering session with GSA drops | Network Security Engineer | 1. Check BGP configuration on the CPE device.<br>2. Verify the peer IP and Autonomous System Number (ASN) settings.<br>3. Review route advertisements for changes. |
| Tunnel MTU-related packet drops | High rate of fragmented or dropped packets on the tunnel | Network Security Engineer | 1. Reduce the tunnel MTU on the CPE device (recommended: 1,400 bytes for GRE, 1,380 for IPsec).<br>2. Enable Transmission Control Protocol (TCP) Maximum Segment Size (MSS) clamping if not already configured. |
 
### KQL queries for remote network monitoring
 
 
| Check | Role | Procedure | What to do if it fails |
| --- | --- | --- | --- |
| Tunnel status | Platform Ops / Monitoring Engineer | Microsoft Entra admin center > **Global Secure Access** > **Connect** > **Remote networks**. Verify all tunnels show **Connected**. | Check CPE device status and ISP connectivity at the affected site. |
| High-severity alerts | SOC Analyst | Review Sentinel or your security information and event management (SIEM) platform for P1/P2 remote network alerts. | Ensure each alert is assigned. Escalate unassigned alerts older than 4 hours. |
| Site traffic volume | Platform Ops / Monitoring Engineer | Spot-check traffic volumes for your largest sites against the baseline. | Investigate significant drops (possible outage) or spikes (possible anomaly). |
 
| Tunnel redundancy validation | Network Security Engineer | For sites with redundant tunnels, verify failover works. See [Tunnel failover testing](#tunnel-failover-testing). | Investigate and resolve failover issues before the next maintenance window. |
MODIFIED docs/identity/authentication/how-to-plan-rdp-phishing-resistant-passwordless-authentication.md
Modified by Justinha on May 11, 2026 5:31 PM
đź“– View on learn.microsoft.com
+21 / -1 lines changed
Commit: Add Windows 11 passkey privacy consent troubleshooting
Changes:
Before
After
title: Considerations for Remote Desktop Connections in a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
description: Remote desktop connection guidance to deploy passwordless and phishing-resistant authentication for organizations that use Microsoft Entra ID.
ms.topic: how-to
ms.date: 03/31/2025
author: mepples21
ms.reviewer: miepping
 
 
In this example, users likely can't use their FIDO2 security keys for remote desktop connection at all because the thin client OS and remote desktop connection client don’t support FIDO2/passkeys in every scenario required. Work with your thin client vendor to understand their roadmap for support. Additionally, plan on Microsoft Entra hybrid joining or Microsoft Entra joining the Target Platform virtual machines so that passkeys can be better supported.
 
## Next steps
 
[Deploy a phishing-resistant passwordless authentication deployment in Microsoft Entra ID](how-to-deploy-phishing-resistant-passwordless-authentication.md)
 
 
 
 
 
 
 
title: Considerations for Remote Desktop Connections in a phishing-resistant passwordless authentication deployment in Microsoft Entra ID
description: Remote desktop connection guidance to deploy passwordless and phishing-resistant authentication for organizations that use Microsoft Entra ID.
ms.topic: how-to
ms.date: 05/11/2026
author: mepples21
ms.reviewer: miepping
 
 
In this example, users likely can't use their FIDO2 security keys for remote desktop connection at all because the thin client OS and remote desktop connection client don’t support FIDO2/passkeys in every scenario required. Work with your thin client vendor to understand their roadmap for support. Additionally, plan on Microsoft Entra hybrid joining or Microsoft Entra joining the Target Platform virtual machines so that passkeys can be better supported.
 
## Troubleshoot Windows 11 passkey privacy consent
 
Windows 11 version 24H2 and later includes privacy controls that let users decide whether passkeys can be used by an app or website. If a user declines the privacy consent prompt, passkey registration and authentication might not work in AVD and RDP sessions.
 
Users might be unable to use or provision passkeys for Microsoft Entra in AVD and RDP sessions because they:
 
- Accidentally refused the privacy consent prompt and selected **No** when asked to allow passkey access.
- Customized the Settings app and hidden the navigation options to the passkey privacy settings.
 
### Resolve the privacy consent issue
MODIFIED docs/identity/saas-apps/confluencemicrosoft-tutorial.md
Modified by Jeevan Desarda on May 12, 2026 6:24 PM
đź“– View on learn.microsoft.com
+6 / -6 lines changed
Commit: Add plugin version details to JIRA and Confluence supported versions
Changes:
Before
After
 
As of now, following versions of Confluence are supported:
 
- Confluence: 5.0 to 5.10
- Confluence: 6.0.1 to 6.15.9
- Confluence: 7.0.1 to 7.20.3
- Confluence: 8.0.0 to 8.9.8
- Confluence: 9.0.1 to 9.5.4
- Confluence: 10.0.2 to 10.2.1
 
> [!NOTE]
> Please note that our Confluence Plugin was last supported on **Ubuntu 16.04**, which is no longer supported. The plugin now supports **only Windows**.
 
As of now, following versions of Confluence are supported:
 
- Confluence: 5.0 to 5.10 (Plugin Version 7.4.4)
- Confluence: 6.0.1 to 6.15.9 (Plugin Version 7.4.4)
- Confluence: 7.0.1 to 7.20.3 (Plugin Version 7.4.4)
- Confluence: 8.0.0 to 8.9.8 (Plugin Version 7.4.4)
- Confluence: 9.0.1 to 9.5.4 (Plugin Version 7.4.4)
- Confluence: 10.0.2 to 10.2.11 (Plugin Version 8.4.4)
 
> [!NOTE]
> Please note that our Confluence Plugin was last supported on **Ubuntu 16.04**, which is no longer supported. The plugin now supports **only Windows**.
MODIFIED docs/identity/saas-apps/jiramicrosoft-tutorial.md
Modified by Jeevan Desarda on May 12, 2026 4:22 PM
đź“– View on learn.microsoft.com
+9 / -3 lines changed
Commit: Update JIRA and Confluence version support and add release history
Changes:
Before
After
author: dhivyagana
ms.reviewer: celested
ms.topic: how-to
ms.date: 05/05/2026
ms.author: dhivyag
ms.custom: sfi-image-nochange
# Customer intent: As an IT administrator, I want to learn how to configure single sign-on between Microsoft Entra ID and JIRA SAML SSO by Microsoft so that I can control who has access to JIRA SAML SSO by Microsoft, enable automatic sign-in with Microsoft Entra accounts, and manage my accounts in one central location.
The scenario outlined in this article assumes that you already have the following prerequisites:
 
[!INCLUDE [common-prerequisites.md](~/identity/saas-apps/includes/common-prerequisites.md)]
- JIRA Core and Software 7.0 to 10.5.1 or JIRA Service Desk 3.0 to 5.12.22 should be installed and configured on Windows 64-bit version.
- JIRA server is HTTPS enabled.
- Note the supported versions for JIRA Plugin are mentioned in below section.
- JIRA server is reachable on the Internet particularly to the Microsoft Entra login page for authentication and should able to receive the token from Microsoft Entra ID.
 
## Supported versions of JIRA
 
* JIRA Core and Software: 7.0 to 10.5.1.
* JIRA Service Desk 3.0 to 5.12.22.
* JIRA also supports 5.2. For more details, select [Microsoft Entra single sign-on for JIRA 5.2](jira52microsoft-tutorial.md).
author: dhivyagana
ms.reviewer: celested
ms.topic: how-to
ms.date: 05/12/2026
ms.author: dhivyag
ms.custom: sfi-image-nochange
# Customer intent: As an IT administrator, I want to learn how to configure single sign-on between Microsoft Entra ID and JIRA SAML SSO by Microsoft so that I can control who has access to JIRA SAML SSO by Microsoft, enable automatic sign-in with Microsoft Entra accounts, and manage my accounts in one central location.
The scenario outlined in this article assumes that you already have the following prerequisites:
 
[!INCLUDE [common-prerequisites.md](~/identity/saas-apps/includes/common-prerequisites.md)]
- JIRA Core and Software 7.0 to 11.3.0 or JIRA Service Desk 3.0 to 5.12.22 should be installed and configured on Windows 64-bit version.
- JIRA server is HTTPS enabled.
- Note the supported versions for JIRA Plugin are mentioned in below section.
- JIRA server is reachable on the Internet particularly to the Microsoft Entra login page for authentication and should able to receive the token from Microsoft Entra ID.
 
## Supported versions of JIRA
 
* JIRA Core and Software: 7.0 to 11.3.0.
* JIRA Service Desk 3.0 to 5.12.22.
* JIRA also supports 5.2. For more details, select [Microsoft Entra single sign-on for JIRA 5.2](jira52microsoft-tutorial.md).
MODIFIED docs/global-secure-access/reference-communication-plan.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+6 / -6 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
## Communication checklist
 
- [ ] Prechange notification drafted and reviewed
- [ ] Help desk briefed and knowledge base updated with expected issues and responses
- [ ] Prechange notification sent to all audiences in the stakeholder notification matrix
- [ ] Day-of reminder sent (for major changes affecting many users)
- [ ] Post-change notification sent after the change completes
- [ ] Help desk debriefed on any unexpected issues reported during the change
 
## Escalation during change
 
 
## Communication checklist
 
- Prechange notification drafted and reviewed
- Help desk briefed and knowledge base updated with expected issues and responses
- Prechange notification sent to all audiences in the stakeholder notification matrix
- Day-of reminder sent (for major changes affecting many users)
- Post-change notification sent after the change completes
- Help desk debriefed on any unexpected issues reported during the change
 
## Escalation during change
 
MODIFIED docs/global-secure-access/overview-operations.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+3 / -3 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
- **Platform operations and monitoring engineers** who manage health checks, automation, and dashboards
- **Security leadership** reviewing operational metrics and service value
 
This guide assumes Global Secure Access is already deployed and configured. For deployment and initial setup, see the [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro). For broader identity-layer security investigations and incident response, see the [Entra Security Operations Guide](https://aka.ms/AzureADSecOps).
 
## Overview
 
| [Private Access operations](how-to-operate-private-access.md) | Connector health, application segment management, ZTNA-specific alerting, Graph API automation for connector and app management |
| [Internet Access operations](how-to-operate-internet-access.md) | Web filtering policy management, Transport Layer Security (TLS) inspection, URL categorization, threat blocking metrics |
| [Remote Networks operations](how-to-operate-remote-networks.md) | GRE/IPsec tunnel monitoring, branch site capacity management, customer-premises equipment (CPE) device health, tunnel failover testing |
| [Microsoft Traffic operations](how-to-operate-microsoft-traffic.md) | Microsoft 365 traffic profile management, compliant network enforcement, M365 endpoint coverage, service performance monitoring |
 
### Templates and checklists
 
 
- [Global Secure Access documentation](/entra/global-secure-access/)
- [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro)
- [Entra Security Operations Guide](https://aka.ms/AzureADSecOps)
- [Microsoft Entra what's new](/entra/fundamentals/whats-new)
- **Platform operations and monitoring engineers** who manage health checks, automation, and dashboards
- **Security leadership** reviewing operational metrics and service value
 
This guide assumes Global Secure Access is already deployed and configured. For deployment and initial setup, see the [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro). For broader identity-layer security investigations and incident response, see the [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps).
 
## Overview
 
| [Private Access operations](how-to-operate-private-access.md) | Connector health, application segment management, ZTNA-specific alerting, Graph API automation for connector and app management |
| [Internet Access operations](how-to-operate-internet-access.md) | Web filtering policy management, Transport Layer Security (TLS) inspection, URL categorization, threat blocking metrics |
| [Remote Networks operations](how-to-operate-remote-networks.md) | GRE/IPsec tunnel monitoring, branch site capacity management, customer-premises equipment (CPE) device health, tunnel failover testing |
| [Microsoft Traffic operations](how-to-operate-microsoft-traffic.md) | Microsoft 365 traffic profile management, compliant network enforcement, Microsoft 365 endpoint coverage, service performance monitoring |
 
### Templates and checklists
 
 
- [Global Secure Access documentation](/entra/global-secure-access/)
- [Global Secure Access deployment guide](/entra/architecture/gsa-deployment-guide-intro)
- [Microsoft Entra Security Operations Guide](https://aka.ms/AzureADSecOps)
- [Microsoft Entra what's new](/entra/fundamentals/whats-new)
MODIFIED docs/global-secure-access/reference-daily-health-check.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+2 / -2 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
| # | Check | Status | What to do if it fails |
| --- | --- | --- | --- |
| 1 | All connectors show **Active** in Entra admin center > Global Secure Access > Connect > Connectors | Pass / Fail | Restart the connector service. If unresolved, check network connectivity and Windows Event Logs on the connector host. |
| 2 | No unassigned P1/P2 Private Access alerts in Sentinel | Pass / Fail | Assign and investigate. Escalate alerts older than 4 hours. |
| 3 | Audit logs reviewed—no unauthorized configuration changes | Pass / Fail | Flag unrecognized changes. Verify each change maps to an approved change request. |
 
 
| # | Check | Status | What to do if it fails |
| --- | --- | --- | --- |
| 7 | All tunnels show **Connected** in Entra admin center > Global Secure Access > Connect > Remote networks | Pass / Fail | Check the customer premises equipment (CPE) device status and internet service provider (ISP) connectivity at the affected branch. |
| 8 | No unassigned P1/P2 Remote Networks alerts in Sentinel | Pass / Fail | Assign and investigate. Escalate alerts older than 4 hours. |
| 9 | Traffic volumes for major sites are within baseline range | Pass / Fail | Investigate significant drops (possible outage) or spikes (possible anomaly). |
 
 
| # | Check | Status | What to do if it fails |
| --- | --- | --- | --- |
| 1 | All connectors show **Active** in Microsoft Entra admin center > Global Secure Access > Connect > Connectors | Pass / Fail | Restart the connector service. If unresolved, check network connectivity and Windows Event Logs on the connector host. |
| 2 | No unassigned P1/P2 Private Access alerts in Sentinel | Pass / Fail | Assign and investigate. Escalate alerts older than 4 hours. |
| 3 | Audit logs reviewed—no unauthorized configuration changes | Pass / Fail | Flag unrecognized changes. Verify each change maps to an approved change request. |
 
 
| # | Check | Status | What to do if it fails |
| --- | --- | --- | --- |
| 7 | All tunnels show **Connected** in Microsoft Entra admin center > Global Secure Access > Connect > Remote networks | Pass / Fail | Check the customer premises equipment (CPE) device status and internet service provider (ISP) connectivity at the affected branch. |
| 8 | No unassigned P1/P2 Remote Networks alerts in Sentinel | Pass / Fail | Assign and investigate. Escalate alerts older than 4 hours. |
| 9 | Traffic volumes for major sites are within baseline range | Pass / Fail | Investigate significant drops (possible outage) or spikes (possible anomaly). |
 
MODIFIED docs/global-secure-access/reference-private-access-health-check.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+2 / -2 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
| # | Check | How | Status | What to do if it fails |
| --- | --- | --- | --- | --- |
| 1 | All connectors **Active** | Entra admin center > **Global Secure Access** > **Connect** > **Connectors** | Pass / Fail | Restart the `Microsoft Entra private network connector` service. Check outbound connectivity to `*.msappproxy.net:443`. Review Windows Event Logs on the connector host. |
| 2 | Connector resource utilization normal | Check CPU and memory on each connector host via your monitoring tool | Pass / Fail | If CPU > 80% or memory > 85%, investigate high-traffic applications and consider adding a connector to the group. |
| 3 | No unassigned P1/P2 alerts | Review Private Access alerts in Sentinel or your security information and event management (SIEM) platform from the last 24 hours | Pass / Fail | Assign and begin investigation. Escalate alerts unassigned for more than 4 hours. |
| 4 | Audit log—no unauthorized changes | Run the [audit log KQL query](how-to-operate-private-access.md#kql-queries-for-private-access-monitoring) for the last 24 hours | Pass / Fail | Verify each change maps to an approved change request. Flag unrecognized changes and investigate. |
| --- | --- | --- | --- | --- |
| 1 | Connector software version | Compare installed version on each host against the [latest available version](/entra/global-secure-access/concept-connectors) | Pass / Fail | Schedule connector updates during a maintenance window. Update one connector at a time per group. |
| 2 | Failover validation | Follow the [failover validation procedure](how-to-operate-private-access.md#failover-validation) during a scheduled maintenance window | Pass / Fail | Investigate connector group assignment and network routing. Don't run in production without a maintenance window. |
| 3 | Role-based access control (RBAC) review | Review accounts with Global Secure Access Administrator or related roles in the Entra admin center | Pass / Fail | Remove access for accounts that no longer require it. Verify all admin accounts use phishing-resistant MFA. |
| 4 | Capacity assessment | Review 30-day trend of concurrent sessions and bandwidth per connector group against [capacity thresholds](how-to-operate-private-access.md#capacity-thresholds) | Pass / Fail | If any group is consistently above 70%, plan to add connectors. Use the [Private Access Sizing Planner](https://github.com/FranckhDev/GSA-Private-Access-Sizing-Planner). |
| 5 | Stale segment cleanup | Identify application segments with zero traffic in the last 90 days using [automation playbook #6](how-to-operate-private-access.md#automation-playbooks) | Pass / Fail | Review with application owners before removing. Document removed segments. |
| 6 | Performance baseline comparison | Compare current month's traffic patterns against the [30-day baseline](how-to-operate-private-access.md#kql-queries-for-private-access-monitoring) | Pass / Fail | Investigate significant deviations. Update baseline if traffic growth is expected (for example, new user populations onboarded). |
 
| # | Check | How | Status | What to do if it fails |
| --- | --- | --- | --- | --- |
| 1 | All connectors **Active** | Microsoft Entra admin center > **Global Secure Access** > **Connect** > **Connectors** | Pass / Fail | Restart the `Microsoft Entra private network connector` service. Check outbound connectivity to `*.msappproxy.net:443`. Review Windows Event Logs on the connector host. |
| 2 | Connector resource utilization normal | Check CPU and memory on each connector host via your monitoring tool | Pass / Fail | If CPU > 80% or memory > 85%, investigate high-traffic applications and consider adding a connector to the group. |
| 3 | No unassigned P1/P2 alerts | Review Private Access alerts in Sentinel or your security information and event management (SIEM) platform from the last 24 hours | Pass / Fail | Assign and begin investigation. Escalate alerts unassigned for more than 4 hours. |
| 4 | Audit log—no unauthorized changes | Run the [audit log KQL query](how-to-operate-private-access.md#kql-queries-for-private-access-monitoring) for the last 24 hours | Pass / Fail | Verify each change maps to an approved change request. Flag unrecognized changes and investigate. |
| --- | --- | --- | --- | --- |
| 1 | Connector software version | Compare installed version on each host against the [latest available version](/entra/global-secure-access/concept-connectors) | Pass / Fail | Schedule connector updates during a maintenance window. Update one connector at a time per group. |
| 2 | Failover validation | Follow the [failover validation procedure](how-to-operate-private-access.md#failover-validation) during a scheduled maintenance window | Pass / Fail | Investigate connector group assignment and network routing. Don't run in production without a maintenance window. |
| 3 | Role-based access control (RBAC) review | Review accounts with Global Secure Access Administrator or related roles in the Microsoft Entra admin center | Pass / Fail | Remove access for accounts that no longer require it. Verify all admin accounts use phishing-resistant MFA. |
| 4 | Capacity assessment | Review 30-day trend of concurrent sessions and bandwidth per connector group against [capacity thresholds](how-to-operate-private-access.md#capacity-thresholds) | Pass / Fail | If any group is consistently above 70%, plan to add connectors. Use the [Private Access Sizing Planner](https://github.com/FranckhDev/GSA-Private-Access-Sizing-Planner). |
| 5 | Stale segment cleanup | Identify application segments with zero traffic in the last 90 days using [automation playbook #6](how-to-operate-private-access.md#automation-playbooks) | Pass / Fail | Review with application owners before removing. Document removed segments. |
| 6 | Performance baseline comparison | Compare current month's traffic patterns against the [30-day baseline](how-to-operate-private-access.md#kql-queries-for-private-access-monitoring) | Pass / Fail | Investigate significant deviations. Update baseline if traffic growth is expected (for example, new user populations onboarded). |
MODIFIED docs/backup/backup-difference-report-recovery-model.md
Modified by Ken Withee on May 12, 2026 9:05 PM
đź“– View on learn.microsoft.com
+2 / -0 lines changed
Commit: Clarify Backup and Recovery scope (Entra directory only; not M365/Azure)
Changes:
Before
After
 
Microsoft Entra Backup and Recovery is available for workforce tenants only. Microsoft Entra External ID tenants and Azure AD B2C tenants aren't supported.
 
## Related content
 
- [View available backups](view-available-backups.md)
 
 
 
Microsoft Entra Backup and Recovery is available for workforce tenants only. Microsoft Entra External ID tenants and Azure AD B2C tenants aren't supported.
 
Microsoft Entra Backup and Recovery backs up and recovers Microsoft Entra directory objects. Microsoft 365 resources, such as mailboxes, OneDrive, or SharePoint sites, and Azure resources aren't backed up by Microsoft Entra Backup and Recovery.
 
## Related content
 
- [View available backups](view-available-backups.md)
MODIFIED docs/global-secure-access/reference-licensing-guest-users.md
Modified by Ken Withee on May 12, 2026 3:06 PM
đź“– View on learn.microsoft.com
+1 / -1 lines changed
Commit: GSA ops: address blocking PR review feedback
Changes:
Before
After
 
Guest users are only billed when they actively sign in to the Global Secure Access client for Private Access.
 
You can identify sign-ins that are billed to Microsoft Entra Private Access for guests by looking at your sign-in logs. Under **Entra ID** > **Monitoring & health** > **Sign-in logs**, each billable sign-in has these properties:
 
- **User type**: Guest
- **Cross tenant access type**: B2B collaboration
 
Guest users are only billed when they actively sign in to the Global Secure Access client for Private Access.
 
You can identify sign-ins that are billed to Microsoft Entra Private Access for guests by looking at your sign-in logs. Under **Microsoft Entra ID** > **Monitoring & health** > **Sign-in logs**, each billable sign-in has these properties:
 
- **User type**: Guest
- **Cross tenant access type**: B2B collaboration

🤖 This report was automatically generated by the Entra Docs Monitor

📧 Delivered to [email protected]

đź”— Visit Repository