Global Secure Access: Test Device Signals

A device becoming non-compliant is an administrative event. Stopping its access is a separate outcome. The useful pilot measures the path between them.

Microsoft’s 12 October Entra roundup highlights preview device signals for Global Secure Access continuous access evaluation.

This creates a practical opportunity to test what happens to working sessions when a device’s trusted state changes.

Define the boundary before choosing the test

The Global Secure Access client captures traffic according to configured forwarding profiles. A result observed through that path does not prove anything about an application reached by another route.

Start with one managed test device, one test identity and one harmless application. Record the forwarding profile, applicable Conditional Access policy, client version and evidence showing that the connection uses Global Secure Access. Ask the application owner whether the test can interrupt an operation safely.

Choose a short task that produces an observable result, such as opening a test document. Avoid using a production transfer or a session that holds unsaved work as the first experiment. The purpose is to learn the boundary without making the measurement itself an incident.

Pair the signal with the decision

Microsoft’s Universal CAE documentation lists device deletion, disablement and non-compliance as preview signals. It also says that device compliance and user risk signals need corresponding Conditional Access policies. Without that pairing, reauthentication can happen silently without applying the intended restriction.

That distinction should appear in the change record. Write the rule in plain language: which identity, which resource, which device state and which access decision. A note saying “CAE enabled” leaves the most important part unanswered.

Use the existing device compliance and Conditional Access guide to review the upstream compliance decision. For this pilot, add the missing downstream question: what does the user retain after that decision changes?

Measure a sequence, not one timestamp

Prepare a record with these fields:

The product documentation describes a two-minute reauthentication window after Global Secure Access receives the event. That is not a guarantee that every device-state change will interrupt every session within two minutes. Keep the starting points separate when reporting results.

Also separate client behaviour from application behaviour. An application may display a cached page after its network connection has stopped. Conversely, an application can fail for an unrelated service issue while the access policy is working correctly. Use the logs and an actual network-dependent task to distinguish them.

Do not confuse device compliance with compliant network

The compliant network check evaluates whether access passes through the relevant tenant’s Global Secure Access service. It is a different condition from whether the device meets compliance policy.

Microsoft’s tutorial also explains that disabling the client does not necessarily end an existing application session immediately; a fresh authentication can be needed to demonstrate that particular check. Do not substitute that test for the device-signal experiment and call both successful.

If the organisation intends to use both conditions, test them independently first. Then test their combined behaviour so a failed condition can be identified without guessing.

Include recovery and exceptions

After the restriction test, restore the approved device state through the normal management process. Confirm that a fresh sign-in works and that the application can complete the same task. Record how long it takes for each observed state to update, without turning a single measurement into a service guarantee.

Have a predefined rollback for the pilot policy and assignments. Keep administration available through an approved management route outside the affected test scope. Do not disable continuous access evaluation across the tenant to troubleshoot one device.

The deployment decision should include more than a successful block. Require evidence that traffic was covered, the correct policy acted, the user received usable guidance, access returned after remediation and the service desk could explain the result.

Repeat with the client platforms and network conditions that matter to the business. The preview is useful when its behaviour is understood and bounded. A checkbox cannot replace that evidence.

References

• Microsoft — Microsoft Entra October 2026 announcement, published 12 October 2026. Accessed 17 October 2026.
• Microsoft — Universal Continuous Access Evaluation. Accessed 17 October 2026.
• Microsoft — Global Secure Access client overview. Accessed 17 October 2026.
• Microsoft — Enable the compliant network check. Accessed 17 October 2026.