Treat it as both, but evaluate it first as an access-control problem. The architecture defines who can push policy, how enforcement happens, and whether the control plane can be used as a privileged path into production. If those questions are not answered cleanly, the network design may undermine the access model it is meant to protect.
Why segmentation is partly an access-control decision
Segmentation is not just about where traffic can travel, it is also about who is allowed to change the rules, what authority the enforcement layer has, and whether policy changes can be abused as a privileged path into production. That is why the access-control lens comes first: if control of the segmentation plane is weak, the network boundary is only as strong as the identities and permissions behind it.
In practice, teams should treat the segmentation policy as an authorisation problem with network consequences. The central questions are who can create, edit, approve, and deploy policy; whether those actions are separated from day-to-day administration; and whether the control point itself is protected from the same blast radius it is meant to contain.
That is the same reason Authorisation Models Guide is relevant here: segmentation policies behave like high-impact entitlements, not ordinary routing preferences. If policy changes are too broad, too informal, or too easy to reuse across environments, the resulting network posture becomes a privileged access problem in disguise.
How network design and enforcement change the answer
The network side still matters because segmentation ultimately depends on enforcement. A design that is conceptually sound can fail if policy enforcement points are inconsistent, bypassable, or managed through a control plane that itself has broad administrative reach. In that case, the architecture is not only defining traffic paths, it is defining the trust boundary for production access.
This is where segmentation often overlaps with privileged access management, remote administration, and zero trust thinking. Micro-segmentation, ZTNA-style access paths, service-to-service controls, and device posture checks are all ways of narrowing what can talk to what, but the practical question is whether the rules are enforced at the point of access or merely documented after the fact.
For that reason, NIST SP 800-207 Zero Trust Architecture is a strong reference point for the enforcement model, while CIS Controls v8 reinforces the operational need to manage accounts, restrict access, and keep administrative pathways under control. Segmentation is strongest when the network policy and the access policy are aligned rather than layered independently.
ISO/IEC 27001:2022 Information Security Management also fits naturally where the question is governance over access boundaries, because segmentation decisions affect asset protection, privileged operations, and the integrity of security controls. The practical issue is not simply where the firewall sits, but whether the organisation can prove that the segmentation design is controlled, reviewed, and consistently enforced.
What practitioners should check before calling segmentation “done”
The easiest mistake is to design segmentation as a network diagram and only later discover that the enforcement workflow gives too many people too much power. If the same team that operates production can freely alter segmentation rules, or if policy changes are not tightly reviewed, the segmentation model can become a route around controls rather than a barrier.
Another common failure mode is assuming that perimeter segmentation solves internal trust. Modern environments usually need both external and east-west controls, and the real risk sits in the exceptions: shared admin paths, temporary openings that never close, unmanaged service access, and control-plane credentials that can modify the policy fabric itself.
Teams should verify that the control plane is at least as protected as the workloads it governs, that changes are attributable, and that policy drift is detectable. Where segmentation is implemented through platform automation, the access model for that automation is part of the security design, not an implementation detail.
NHIMG’s IAM and IGA Basics is useful here because segmentation programs often fail at the boundary between network operations and access governance. If entitlements, approvals, and recertification are weak, segmentation becomes a brittle control that looks technical but behaves like unmanaged privilege.
Risk and Threat Considerations
Segmentation failures create two classes of exposure: direct lateral movement inside the network and indirect compromise through the policy layer itself. An attacker does not need to “break segmentation” if they can obtain the rights to alter rules, access the management plane, or reuse an administrative path that was never meant to reach production systems.
Failure mechanism: Weak governance over segmentation policy, broad administrative access, or uncontrolled exception handling turns the segmentation fabric into a privileged pathway, allowing attackers or over-privileged operators to widen access, bypass intended barriers, or move laterally after initial compromise.
Impact: Once the control plane is exposed, the blast radius is no longer limited to one segment. Compromise can expand across tiers, undermine containment, and make detection harder because policy changes themselves may look like legitimate administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Segmentation enforces who and what may communicate across boundaries. |
| AC-6 — Least Privilege | Segmentation policy administration should be limited to essential operators. | |
| CM-3 — Configuration Change Control | Segmentation rules are high-impact configuration changes that need control. | |
| Recommendation — Enforce AC-4 at segment boundaries to restrict approved information flows. Apply AC-6 to restrict segmentation changes to the minimum necessary administrators. Use CM-3 to review and approve segmentation policy changes before deployment. | ||
| NIST Zero Trust (SP 800-207) | NIST SP 800-207 — Zero Trust Architecture | Zero trust directly addresses segmentation as an enforcement and trust-boundary problem. |
| Recommendation — Design segmentation so every access decision is evaluated at the point of enforcement. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Segmentation depends on controlling who can reach and modify critical systems. |
| Recommendation — Use CIS-6 to restrict and review access to segmentation administration paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Segmentation is an access-boundary control that requires policy governance. |
| A.8.20 — Network security | Network segmentation is a core network-security control for traffic separation. | |
| A.8.9 — Configuration management | Segmentation depends on controlled configuration of enforcement points. | |
| Recommendation — Implement A.5.15 to define and enforce access boundaries consistently. Apply A.8.20 to segment networks and control inter-zone traffic. Use A.8.9 to govern segmentation configuration changes and prevent drift. | ||
Practitioner Guidance
What to prioritise: Treat segmentation changes as security-sensitive access changes, not routine network tuning. Start by identifying who can modify policy, who can approve exceptions, and which accounts or automation paths can reach the management plane.
What to verify: Check that enforcement is consistent across environments, that production policy changes are logged and reviewable, and that emergency openings have expiry conditions. If you cannot show who changed the rule, why it changed, and when it will be removed, the control is too loose to trust.
Common mistake: Teams often harden packet flow while leaving policy administration overexposed. That produces a false sense of safety, because the segmentation boundary may be sound on paper but still collapses if the control plane is compromised.
Practitioner takeaway: The right mental model is “network enforcement with access governance,” not “network design versus access control.” Segmentation only reduces risk when the path, the policy, and the privilege to change both are all bounded together.
Related resources from NHI Mgmt Group
- What happens when host workloads and network teams treat segmentation as the same control?
- Should compliance teams treat network segmentation as a security control or a scoping control?
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between OT network segmentation and identity-based access control?