Zero trust network access (ZTNA)

The request, step by step

1. Ask for an application, not for the network

   The user names the application they need and the local agent opens an outbound session to the broker. Nothing about this step puts the device on the private network, so there is no interval during which the device is connected but not yet governed.

   • Request: Contractor to Laptop with access agent, “Asks for the finance application by name”
   • Request: Laptop with access agent to ZTNA broker, “Outbound session from the agent”

   Emphasised at this step: ZTNA broker.

2. Build the context for this request

   Identity and a second factor come from the identity provider, device posture comes from the agent, and the broker adds the application that was actually requested. Together these are the request, and the request is what gets authorised.

   • Context: Contractor to Identity provider, “Authentication and a second factor”
   • Context: Identity provider to Policy engine, “Identity, group and risk claims”
   • Context: Laptop with access agent to Continuous evaluation, “Device posture, at connect and while running”
   • Request: ZTNA broker to Policy engine, “This identity, this device, this application”

   Emphasised at this step: Identity provider.

3. Decide one application at a time

   The policy engine returns a verdict scoped to this identity, this device and this application, with any step-up requirement and the interval at which the session must justify itself again. A verdict for one application says nothing about the next one.

   • Request: Policy engine to ZTNA broker, “Verdict for one application and one session”

   Emphasised at this step: Policy engine.

4. Stitch the session from two outbound halves

   The connector has already dialled out from inside the private network. The broker joins that tunnel to the user's session, and traffic reaches the named application only. Neither half of the path required an inbound firewall rule.

   • Request: Application connector to ZTNA broker, “Outbound tunnel raised from the inside”
   • Request: ZTNA broker to Application connector, “Authorised session handed over”
   • Request: Application connector to Finance reporting application, “Reaches one application, not the network”
   • Request: Finance reporting application to Finance records, “Application reads its own records”

   Emphasised at this step: Application connector.

5. Keep checking while the session runs

   Posture, risk and location are re-evaluated on a configured interval and on defined triggers. If the context that justified the session stops being true, the verdict changes and the session ends rather than running to its own timeout.

   • Context: Continuous evaluation to Policy engine, “Signals for the next re-evaluation”

   Emphasised at this step: Continuous evaluation.

6. Record what was reachable, and when

   The broker, the policy engine and the connector each report to security operations. That record is what lets an investigator state which application a given identity could reach at a given time, which is a question a network-level grant cannot answer precisely.

   • Telemetry: ZTNA broker to Security operations, “Session start, duration and re-evaluations”
   • Telemetry: Policy engine to Security operations, “Every verdict and the signals behind it”
   • Telemetry: Application connector to Security operations, “Connector health and published applications”

   Emphasised at this step: Security operations.

Attempts shown, and where each one stops

• Adversary on the internet attempts:

  • Attack: Adversary on the internet to Application connector, “Scans the perimeter for a service to reach”
  • Attack: Adversary on the internet to ZTNA broker, “Stolen credentials replayed at the broker”
  • Terminated here by Application connector — “Nothing listens inbound to be found”. The line stops short and takes a bar, not an arrowhead.
  • Terminated here by ZTNA broker — “Refused: unknown device, no posture signal”. The line stops short and takes a bar, not an arrowhead.

• Laptop with access agent attempts:

  • Attack: Laptop with access agent to Ticketing application, “Compromised session probes the next system”
  • Terminated here by ZTNA broker — “The grant names one application only”. The line stops short and takes a bar, not an arrowhead.

Annotations

1. Why this path runs outward

   Relationship — Request: Application connector to ZTNA broker, “Outbound tunnel raised from the inside”

   Both halves of the session are initiated from inside a network towards the broker, which is the whole reason no inbound rule is needed. Reverse this one arrow and you are back to publishing a listener on the internet and defending it.

2. A scan with nothing to find

   Relationship — Blocked: Adversary on the internet stopped at Application connector, “Nothing listens inbound to be found”

   This attempt does not reach a control that says no. It reaches an address where no service is listening, because the connector only ever makes outbound connections. The strongest refusal is the one that needs no rule to be correct.

3. What a compromised session can still try

   Relationship — Attack: Laptop with access agent to Ticketing application, “Compromised session probes the next system”

   ZTNA does not assume the endpoint stays honest. A session that is misused can attempt the neighbouring system, and the attempt fails because the broker holds a grant for one application rather than because the endpoint behaved well.

4. The broker is the only path

   Component “ZTNA broker”

   The broker holds both halves of every session and can end either. It is also a single dependency worth planning for, since an unreachable broker means no access at all, and any bypass built to soften that becomes the broad path ZTNA was bought to remove.

5. Continuous is an interval, not a promise

   Component “Continuous evaluation”

   Re-evaluation happens as often as it is configured to, over the signals that are actually collected. A deployment that checks posture once at connect and then leaves an eight-hour session running has one-time authentication with a newer label on it.

6. The definition decides how narrow this is

   Component “Policy engine”

   The engine can only be as precise as the application definitions it evaluates. An application entered as a subnet, or a group that contains most of the workforce, produces a grant no narrower than the VPN it replaced while still reporting per-request decisions.

7. Being inside grants nothing here

   Boundary “Private application network” (internal)

   The connector sits in the internal zone and its neighbours are ordinary systems with ordinary weaknesses. What changes is that arriving from outside no longer places anyone on this network, so the neighbours are not part of the reachable surface.