A remote worker opens payroll from untrusted Wi-Fi

The request, step by step

1. Arrive somewhere the network cannot vouch for

   The analyst opens payroll from a shared hotel network and the laptop builds an encrypted session to the nearest enforcement point. Nothing about being on that network raises or lowers the verdict; it only decides where the decision has to be made, which is outside the network itself.

   • Request: Finance analyst to Managed laptop, “Opens payroll at 08.42”
   • Request: Managed laptop to Access broker, “Encrypted session to the nearest edge”

   Emphasised at this step: Access broker.

2. Establish who is asking

   Sign-in and a second factor succeed, and the identity provider passes identity, group and risk claims to the policy engine while the broker presents the request. This answers who is asking and nothing more.

   • Context: Finance analyst to Identity provider, “Sign-in and a second factor”
   • Context: Identity provider to Policy engine, “Identity, group and risk claims”
   • Request: Access broker to Policy engine, “Request presented for one decision”

   Emphasised at this step: Identity provider.

3. Weigh the device against the request

   The laptop reports posture, and the signature age is the weak signal in an otherwise strong request. Rather than deny a legitimate analyst or wave the request through, the engine requires stronger verification and holds a data restriction ready for the part of the session that would actually move salaries onto that disk.

   • Context: Managed laptop to Policy engine, “Device posture: signatures four days old”
   • Request: Policy engine to Identity provider, “Stronger verification required”
   • Context: Identity provider to Access broker, “Step-up challenge satisfied”

   Emphasised at this step: Policy engine.

4. Open one application, not a network

   The broker opens a session to the payroll interface alone and makes the outbound connection itself, so payroll publishes nothing inbound and nothing else on that estate becomes reachable. The application reads its own records as it always did.

   • Request: Access broker to Payroll application, “Brokered session, no network route”
   • Request: Payroll application to Payroll records, “Application reads payroll records”

   Emphasised at this step: Payroll application.

5. Constrain what may move

   The verdict reaches the inspection services with the restriction attached: the interactive session proceeds, and the monthly export does not land on a device with stale defences. The restriction is a consequence of a signal, so it lifts when the signal changes.

   • Request: Policy engine to Inspection and data controls, “Verdict: allow the session, refuse the file”

   Emphasised at this step: Inspection and data controls.

6. Govern the other way out

   The same rules follow the data to the sanctioned cloud spreadsheet service the analyst uses for every other report, because a refusal at one channel otherwise just moves the behaviour to the next one.

   • Request: Inspection and data controls to Cloud spreadsheet service, “Inspected traffic to a sanctioned service”

   Emphasised at this step: Cloud spreadsheet service.

7. Leave a record somebody can read

   Session, decision and inspection events reach security operations with the signals attached, which is what lets an investigator answer why this request was allowed six weeks later, and what lets an architect notice a rule that is refusing work it should permit.

   • Telemetry: Access broker to Security operations, “Session and application events”
   • Telemetry: Policy engine to Security operations, “The verdict and the signals behind it”
   • Telemetry: Inspection and data controls to Security operations, “Inspection and data-handling events”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Another guest on the network attempts:

  • Attack: Another guest on the network to Managed laptop, “Credential capture on the shared segment”
  • Attack: Another guest on the network to Access broker, “Captured credentials replayed at the edge”
  • Terminated here by Access broker — “Refused: unknown device, no posture signal”. The line stops short and takes a bar, not an arrowhead.

• Managed laptop attempts:

  • Attack: Managed laptop to Payroll records, “Monthly export pulled toward a stale device”
  • Terminated here by Inspection and data controls — “Export refused while signatures are stale”. The line stops short and takes a bar, not an arrowhead.

Annotations

1. Untrusted is a description, not an accusation

   Boundary “Hotel Wi-Fi” (untrusted)

   The badge states what is known about the network: its operator, its other occupants and its configuration are all outside the enterprise's knowledge. It says nothing about the laptop inside it, which is still managed and still reporting. Equally, a device sitting in an internal zone earns no privilege from the enclosure it happens to be drawn in.

2. Why this line changes the verdict without deciding it

   Relationship — Context: Managed laptop to Policy engine, “Device posture: signatures four days old”

   Posture arrives as context rather than as a request, and that is the whole argument of this page. A signal of this kind should shift what a session is allowed to do; it should not by itself decide whether the session happens. Wired as a gate, the same signal produces an exception ticket approved by someone holding less information than the engine had.

3. The challenge is triggered, not routine

   Relationship — Request: Policy engine to Identity provider, “Stronger verification required”

   Stronger verification is asked for because a second signal turned weak, not because a policy applies it to everyone every morning. Friction applied uniformly is friction people learn to route around, and the routes they find are the paths nobody is inspecting.

4. What the terminated download tells you

   Relationship — Blocked: Managed laptop stopped at Inspection and data controls, “Export refused while signatures are stale”

   This line stops short of the laptop on purpose: the attempt ended at the control rather than at the device. Reading salaries in a browser and holding a spreadsheet of them on a disk are different exposures, and only the second one outlives the session, so only the second one is refused.

5. Why a captured credential is not enough

   Relationship — Blocked: Another guest on the network stopped at Access broker, “Refused: unknown device, no posture signal”

   The replayed credential is genuine, which is exactly why a design that stops at authentication fails here. The attempt terminates because the device presenting it is unknown and can produce no posture signal at all, so a second requirement it cannot satisfy is what ends the attempt.

6. A session, not a route

   Relationship — Request: Access broker to Payroll application, “Brokered session, no network route”

   The broker connects outward to the named application, so the payroll estate publishes no listening service for anyone to scan and reachability never becomes transitive. The cost is an application inventory somebody has to maintain, because an application nobody enumerated is an application nobody can reach.

7. Where the observable channels end

   Relationship — Request: Inspection and data controls to Cloud spreadsheet service, “Inspected traffic to a sanctioned service”

   This route is governed because the service terminates it and can apply the same sensitivity rules. A personal account on an unsanctioned service, or a copy made on an earlier trip, is outside what any of these controls observe. Naming that boundary is more useful than implying it is not there.

8. A verdict nobody can reconstruct is a guess

   Component “Security operations”

   The useful record is not the allow and the block but the signals behind them: which identity, which device, its posture at that moment, which application, which control fired. If those events cannot leave the service, or their clocks disagree with the endpoint and application logs, the architecture cannot be audited.