Skip to content
←Security

// Security · 10

Zero Trust

Trust the networkleads toVerify each requestleads toLeast access, always

No implicit trust from the network; verify every request.

How it fits together

Zero Trust structure«client»Remote useridentity + devicePolicy engineidentity, device, riskPolicy enforcementchecks every requestLateral attackeron the internal networkOrders servicescopes per route1 HTTPS + token2 ask: allowed?3 allowed call4 no identity
uses / callsfails / error path· numbered steps replay in order
  • Remote user uses / calls Policy enforcement (1 HTTPS + token)
  • Policy enforcement uses / calls Policy engine (2 ask: allowed?)
  • Policy enforcement uses / calls Orders service (3 allowed call)
  • Lateral attacker fails / error path Orders service (4 no identity)

Spot it

  • Internal APIs open to anything on the VPN
  • One stolen VPN login exposes every service
  • Attacker moves sideways after one breach

It costs

Every hop authenticates and gets logged, so there is more policy to design and run.

Go deeperThe full explanation and what to ask for · 1 min readExpand

Zero trust replaces the idea of a trusted inside network with one rule: no request is allowed because of its source address alone. Each request must prove who it comes from (a user or a workload) and, where it matters, from what device, and it is then authorised against the specific resource. A VPN gives you a door into the building; zero trust checks the badge at every room.

The working parts are strong identity for users and workloads (short-lived tokens, mTLS certificates), a policy decision point with enforcement in front of each resource, and micro-segmentation so that only the flows you need exist: Orders may call Payments, and nothing else may call either. Continuous verification re-evaluates a session when the device or the risk changes. Logging every decision makes the policy testable.

It is a direction, not a product. Start where the blast radius is largest: the services that move money or personal data. Expect costs in latency, certificate handling and policy upkeep. When NOT to go all the way: a single small app with one database and no internal services gains little from a policy engine; authentication on each endpoint and least privilege already cover most of it.

Ask for it

  • identity-based access
  • micro-segmentation
  • policy decision / enforcement point
  • device posture
  • continuous verification
  • assume breach

Stop trusting the internal network for the Orders API: require a verified identity (mTLS certificate or token) on every call, check scopes per route, and allow in network policy only Orders to Payments on port 443. Log each decision with identity and device. Expire sessions on posture change.

Connects to