Global Secure Access: Pilot Partner Access

A contractor needs one internal application. The access design should be able to name that application, the identity allowed to use it and the condition that ends the assignment.

Microsoft’s 12 October Entra roundup highlights preview external-user access through Global Secure Access.

A useful pilot begins with a real partner workflow and a limited resource, rather than an entire network range.

Agree the scope with both organisations

Identify the resource tenant, the partner’s home tenant, the application owner and the person who approves the contractor’s access. Record the device type and who manages it. “Partner laptop” is not enough detail to explain a compliance failure later.

The external-user documentation requires the external identity, a Private Access profile assignment and an assigned private application in the resource tenant. It also describes resource-tenant subscription linking and the client configuration required for the feature. Review these prerequisites before promising the partner a working connection.

Write an acceptance statement in business terms. For example: the named test user can open the test application and read an approved sample record, while an unassigned partner identity cannot connect. This is an illustrative test design, not a claim about a completed deployment.

Keep the existing access route available during the bounded pilot, with clear instructions about which route testers should use. Uncontrolled switching makes failures difficult to attribute.

Test tenant switching as a user journey

Switching the client to a resource tenant changes the active routing context. Microsoft documents that home-tenant tunnels are disconnected in the external-user switching scenario. It also warns that existing application connections, such as RDP, can remain connected to the previous tenant.

That combination matters. A client showing a new organisation is not proof that every previous session has ended, or that the partner’s normal internet controls are still being supplied by their home tenant.

Have the partner’s administrator observe the test with you. Open the intended application, switch tenant context, and check which new connections succeed. Review an existing harmless connection separately. Document what the user should close before switching and how to return to normal work.

Do not extrapolate the Windows client result to every mobile or virtual desktop arrangement. Use the documented path for the device and identity combination being deployed.

Decide which devices are acceptable

Microsoft’s BYOD documentation distinguishes supported behaviour by platform and registration state. For Windows Entra-registered devices, the documented BYOD path is Private Access traffic. macOS has its own management requirement.

Use those boundaries to write a device acceptance rule that the service desk can apply. If a particular unmanaged device type is outside the supported design, say so before issuing setup instructions. Do not treat a successful registration as evidence that the device meets your security standard.

Ask the partner to confirm how they report a lost device, a compromised account and a departed contractor. Record the contact and expected handoff. Technical trust between tenants does not supply an operational incident contact.

Collect evidence from both layers

Create a small evidence sheet for the pilot.

Use the resource tenant’s traffic logs to distinguish external-user traffic. Microsoft documents the cross-tenant access type and home-tenant identifier for that purpose. Pair the network event with the application result; network reachability does not establish that an application role is appropriately restricted.

For the exit test, remove the test assignment through the approved process and check a fresh connection. Treat existing sessions as a separate observation and follow the application’s supported termination process where needed.

Expand only after the support process works

Set a review date for the pilot and agree who can reverse its assignments and client configuration. If access is unreliable, pause expansion and restore the documented previous route for the test group. Avoid weakening broad Conditional Access settings to accommodate one unexplained failure.

Partner access also needs recurring ownership. Use the existing approach to guest access reviews as a prompt to confirm the sponsor and continuing business need, while keeping this application’s network checks in the record.

A successful pilot should leave a repeatable onboarding path, a diagnosable failure path and a tested exit. Those are the conditions for adding the next partner application.

References

• Microsoft — Microsoft Entra October 2026 announcement, published 12 October 2026. Accessed 17 October 2026.
• Microsoft — Overview of external user access with Global Secure Access. Accessed 17 October 2026.
• Microsoft — Global Secure Access bring-your-own-device support. Accessed 17 October 2026.