Global Secure Access Deep Dive: Following the Sign-In, Not the Packet

Speakers

• Christopher Brumm

About this session

Global Secure Access is usually run as a network project. But the moment the first client is enrolled, things show up in the tenant that nobody registered: enterprise applications you did not create, sign-in entries for resources that are not web apps, and a network attribute Conditional Access suddenly has something to say about. This session stays on the Entra side and follows a sign-in from the client to the policy decision. It starts with the applications Global Secure Access brings into the tenant, what an access to each of them actually represents, and why the split between forwarding profile and application is the thing to understand before writing a policy against them. That split is also where the surprises come from: a sign-in frequency on the wrong object, and internal name resolution starts producing MFA prompts. Then the network condition itself: what the compliant network check proves that a named location cannot, why source IP restoration matters, and where the check sits relative to device compliance. The difference only becomes obvious in the cases that matter. A replayed token, or an intercepted authorization code redeemed by someone who was never near the device that started the flow — in both, the device conditions no longer describe the party presenting the artifact. What is left is the network condition, and only if it cannot be spoofed. Then the other direction: Universal Tenant Restrictions, for when the identity is not one of yours. And the part that gets people hurt: requiring a compliant network tenant-wide is a lockout in waiting. Break-glass accounts, unenrolled devices, guests and platforms without a client all need an answer before the policy goes into report-only, let alone on. Demos and log evidence where it matters — Global Secure Access traffic logs and Entra sign-in logs side by side, including the cases where only one of the two tells you what happened.