Zero Trust & Network Segmentation

Stop assuming everyone inside the building is trustworthy just because they got past the front door — check ID at every internal door too.

At a glance

• What it is: an architecture where no request is trusted just because it comes from “inside the network” — every request is verified, and the network is divided into small segments so access between them is explicit and minimal.
• Why it matters: flat, perimeter-only networks let an attacker who compromises one host move freely to everything else on that network; segmentation limits how far a single breach can spread.
• For developers: don’t assume a call from “inside the VPC/VPN” is automatically safe — services should still authenticate and authorize each other, the same as if the caller were external.
• When to use it: for any network hosting more than one sensitivity tier of system (e.g. payment services next to internal tooling) — which describes most production environments.
• When not to use it: a single-purpose, fully isolated environment with nothing else to segment from has less to gain, but the “verify every request” principle still applies.
• Prerequisites: Identity & Access Management (IAM) — segmentation decisions are enforced using verified identities.

Mental model

flowchart TB
    subgraph Before["Before: Flat network"]
        A1[Compromised laptop] -.->|unrestricted| W1[Warehouse service]
        A1 -.->|unrestricted| P1[Payment service]
    end
    subgraph After["After: Segmented, zero trust"]
        A2[Compromised laptop] -->|denied by policy| W2[Warehouse service]
        A2 -->|denied by policy| P2[Payment service]
        W2 -->|explicitly allowed, verified| P2
    end

Step-by-step walkthrough

1. Map which services need to talk to which — most flat networks allow far more paths than are actually used.
2. Group systems into segments by sensitivity and function (e.g. payment, warehouse, internal tooling).
3. Default-deny traffic between segments, then explicitly allow only the specific, verified paths identified in step 1.
4. Require every cross-segment call to authenticate (mutual TLS or service identity), not just be “on the right subnet.”
5. Continuously verify, not just at connection time — session and device posture can be re-checked, not trusted indefinitely.

Worked example

The same phishing incident from Identity & Access Management reveals a bigger problem: because the corporate network is flat, the compromised laptop could have reached the warehouse and payment services directly, with nothing checking whether it should be allowed to.

• Input: a single compromised host on a network with no internal segmentation — one foothold has a path to every other service.
• Process: the team runs a threat-modeling pass (see Threat Modeling & Risk Assessment) to map which services genuinely need to talk to each other, then segments the network into zones with default-deny between them and mutual TLS for the explicitly allowed paths.
• Output: even if a laptop is compromised again, it has no direct network path to payment or warehouse services — an attacker would need to separately compromise a service identity trusted for that specific path. Concretely, this is Network Security Groups on each spoke VNet defaulting to deny, Azure Firewall in the hub enforcing the explicitly allowed paths, and workload identities via Microsoft Entra Workload ID authenticating each service-to-service call rather than trusting network location.

resource paymentSqlPe 'Microsoft.Network/privateEndpoints@2023-09-01' = {
  name: 'pe-payment-sql'
  location: location
  properties: {
    subnet: { id: paymentSubnetId }
    privateLinkServiceConnections: [
      { name: 'payment-sql-connection', properties: { privateLinkServiceId: sqlServerId, groupIds: ['sqlServer'] } }
    ]
  }
}

resource paymentNsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
  name: 'nsg-payment-subnet'
  location: location
  properties: {
    securityRules: [
      {
        name: 'deny-all-inbound'
        properties: {
          priority: 4096
          direction: 'Inbound'
          access: 'Deny'
          protocol: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}

The payment SQL database has public network access disabled entirely and is reachable only via this private endpoint from the payment subnet; the NSG’s default-deny rule is the concrete Policy Enforcement Point named below — explicit allow rules (not shown) then punch only the specific verified paths from step 1.

Common use cases

Use case	When to use	Notes
Payment or other high-sensitivity services share a network with general tooling	Before the next security review	Segment into zones and default-deny cross-zone traffic
A service is compromised	During containment	Segmentation limits lateral movement even before the root cause is found
Adding a new service to the environment	At onboarding	Explicitly define and allow only the paths it needs — don’t add it to a broad, pre-existing trust zone

Advanced details

• Zero trust vs. perimeter security: perimeter security assumes “inside = trusted”; zero trust assumes nothing is trusted by location and verifies every request regardless of origin.
• Microsegmentation: fine-grained segmentation down to the individual workload level, rather than just large network zones.
• Mutual TLS (mTLS): both sides of a connection prove their identity with certificates, so a service can’t be impersonated just by being on the same network.
• NIST SP 800-207 is the named standard behind “zero trust”: it defines the architecture in terms of a Policy Decision Point (evaluates whether a specific request should be trusted) and Policy Enforcement Points (the gates, like the default-deny rules above, that actually allow or block the request) that re-evaluate every request against policy — access is never granted just because a request originates from a given network segment, which is the formal version of the “default-deny between zones” design in the worked example.

Quick reference

Term	Meaning
Zero trust	Verify every request regardless of network location; never trust by default
Segmentation	Dividing a network into zones with controlled traffic between them
Default-deny	Blocking all traffic unless explicitly allowed
Lateral movement	An attacker moving from an initial foothold to other systems on the same network
mTLS	Mutual TLS — both client and server verify each other’s identity
NIST SP 800-207	The standard defining Zero Trust Architecture, including Policy Decision Points and Policy Enforcement Points

Troubleshooting

Symptom	Likely cause	Fix
A compromised host can reach unrelated services	Flat network with no segmentation	Segment by sensitivity/function and default-deny between zones
Internal service calls aren’t authenticated	“Inside the network” is treated as automatically trusted	Require mutual TLS or verified service identity for every call
Nobody knows which cross-service paths are actually needed	No traffic mapping was ever done	Map real traffic before writing segmentation policy, don’t guess

Check your understanding

• Why does a flat network make a single compromised host more dangerous than a segmented one?
• What’s the difference between trusting a request because of its network location versus zero trust?

Related pages

Part of Introduction to Security Architecture. See also Identity & Access Management (IAM), Threat Modeling & Risk Assessment, Cloud Security Posture & Perimeter Defense, and the Glossary.