Network segmentation best practices and NHI access control

At a glance

What this is: This is an analysis of network segmentation best practices, showing how least privilege, third-party limits, monitoring, and visualisation reduce lateral movement and compliance scope.

Why it matters: It matters because segmentation is still one of the few practical controls that can constrain both human and non-human access paths across complex environments without overloading IAM, PAM, and network teams.

By the numbers:

• According to IBM, data breach costs rose from $3.86 million to $4.24 million USD, the highest average total cost in 17 years.
• A recent report found that 44% of organizations experienced a breach in the last 12 months, with 74% saying it was the result of giving too much privileged access to third parties.
• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read StrongDM's article on 7 network segmentation best practices

Context

Network segmentation is the practice of dividing a network into smaller zones so that compromise in one area does not automatically expose everything else. The primary governance problem is not only traffic control, but limiting how far a human user, service account, or third-party path can move once access is granted.

For IAM and NHI programmes, segmentation is an enforcement layer that supports least privilege when identity controls alone are too broad or too slow. It becomes especially relevant where service accounts, vendor access, and administrative workflows cross multiple systems and the security team needs a way to reduce lateral movement without rebuilding the entire access model.

StrongDM’s article frames the operational trade-off well: segmentation is useful only when it stays monitorable, auditable, and simple enough to maintain. Over-segmentation and weak path design can create the same risk they are supposed to reduce, by making policy harder to understand and access exceptions easier to miss.

Key questions

Q: How should security teams apply least privilege in segmented networks?

A: Security teams should define least privilege at the segment boundary first, then narrow access inside each zone by role, function, and data sensitivity. The goal is not only fewer permissions, but fewer paths that can reach sensitive systems. A usable model is one where approved access is easy to explain, monitor, and recertify.

Q: Why does third-party access create more segmentation risk than internal access?

A: Third-party access often combines external connectivity, broad task scope, and weaker visibility into the requester’s environment. That makes it easier for a contractor or vendor session to become a high-value entry path if the segment is not isolated. Segmentation helps, but only when external access is treated as a separate trust class.

Q: How do you know if network segmentation is actually working?

A: You know segmentation is working when a compromise in one zone does not create immediate reach into adjacent systems, and when audit logs can show which identities crossed which boundaries. If the team cannot explain the access path or the boundary exceptions, the segmentation model is too vague to trust.

Q: What is the difference between segmentation and over-segmentation?

A: Segmentation reduces exposure by creating meaningful trust boundaries. Over-segmentation creates so many boundaries and policies that the organisation struggles to maintain them, which can lead to exceptions, confusion, and weaker oversight. The practical test is whether the model remains understandable to the teams who operate it.

Technical breakdown

Network segmentation and lateral movement control

Segmentation works by placing intermediary controls between groups of systems so that an attacker, or an over-privileged insider, cannot move freely after the first access point is breached. In practice, the design can use VLANs, subnets, firewalls, or software-defined overlays, but the governance goal is the same: convert a flat trust model into bounded zones with distinct access rules. This matters because once the environment is divided, the blast radius of a bad credential, compromised host, or misrouted vendor path is materially smaller.

Practical implication: map each trust zone to a specific access policy and review whether any path still allows broad east-west movement.

Least privilege and third-party access paths

Least privilege inside a segmented network means users, services, and vendors only reach the exact resources needed for their role. The article’s third-party discussion shows why this matters: remote access that is broader than task scope becomes a standing shortcut into sensitive systems. Segmentation does not remove identity risk, but it changes the shape of the risk by forcing access to pass through narrower, inspectable paths. For NHI governance, that is particularly important when service accounts or API-based access are reused across multiple environments.

Practical implication: treat third-party and service access as separate path classes and remove any shared route that bypasses contextual controls.

Auditing, visualization, and over-segmentation

A segmented network is only as strong as the team’s ability to see it. Network diagrams, audit trails, and continuous monitoring are what let practitioners verify whether the architecture still matches operational reality. The article also warns against over-segmentation, which creates too many policy relationships and raises administrative complexity. That is a governance problem, not just an engineering one, because complexity increases the odds of drift, exceptions, and blind spots that attackers can exploit.

Practical implication: keep the segment model simple enough to audit regularly, and retire zones that no longer map to a clear business boundary.

Threat narrative

Attacker objective: The attacker aims to turn one compromised access point into broader reach across the environment, especially toward sensitive data and privileged systems.

1. Entry occurs through a flat or weakly segmented network path that gives an attacker a first foothold into one zone.
2. Escalation follows when overly broad internal access or third-party permissions let the attacker move laterally toward sensitive systems.
3. Impact lands when the attacker reaches regulated data or privileged infrastructure that segmentation was supposed to isolate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Network segmentation is now an identity control as much as a network control. The article is about dividing traffic paths, but the real governance outcome is limiting what identities can reach once they are inside. That matters across human users, service accounts, and third parties because the same broad access problem appears in each case. Practitioners should treat segmentation as part of identity blast-radius management, not as an isolated network project.

Third-party access without path isolation is a standing privilege problem in disguise. The article shows that vendor access becomes dangerous when the same path can reach too many internal systems. That is an NHI governance issue as much as a perimeter issue, because vendor sessions, service credentials, and shared remote access can all become long-lived entry routes. Practitioners should separate external access paths from internal operator paths and govern them as distinct risk classes.

Over-segmentation creates a governance failure mode called policy explosion. The article correctly warns that too many zones increase policy burden and operational friction. That failure mode matters because teams stop understanding the rules they are enforcing, which increases exception handling and weakens audit confidence. Practitioners should optimise for manageable trust boundaries, not for the highest possible number of micro-zones.

Legitimate-path design is the strongest practical expression of least privilege. If approved access is easier than illegitimate movement, the environment becomes easier to govern and easier to defend. This is where segmentation, identity, and audit trail design meet. Practitioners should make the correct path the simplest path and verify that the audit trail can still explain every access decision.

Identity blast radius is the concept this article sharpens. Segmentation does not eliminate compromise, but it defines how far compromise can travel from one identity or endpoint. That makes blast radius a measurable governance objective across NHI, human, and third-party access. Practitioners should evaluate segmentation by how much it shrinks reach, not by how many controls it adds.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why segmented access paths remain difficult to govern at scale.
• For the lifecycle angle, see Ultimate Guide to NHIs , Key Challenges and Risks for visibility, rotation, and offboarding patterns that segmentation alone cannot solve.

What this signals

Identity blast radius is becoming the more useful metric than perimeter size. As environments mix people, service accounts, and vendors across cloud and on-prem paths, practitioners should measure how far one compromised identity can travel, not just how many controls sit at the edge. The most useful segmentation programmes are the ones that make access easier to explain and harder to abuse.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, segmentation should be treated as a compensating control for entitlement sprawl, not a substitute for identity governance. Teams that rely on network boundaries alone will still inherit broad internal reach when service identities are over-provisioned.

Practitioners should expect segmentation to become more tightly linked with Zero Trust Architecture and workload identity standards. The direction of travel is toward smaller, more inspectable trust zones, but also toward cleaner identity-to-path mapping so audit, access review, and incident response can all answer the same question: who could reach what, and through which route?

For practitioners

• Map access paths before adding more zones Document the current routes used by users, service accounts, vendors, and administrators, then identify which paths can reach sensitive systems without a clear business need.
• Separate third-party access from internal operator access Place vendor and contractor sessions into isolated portals or tightly scoped segments so their credentials cannot be reused to traverse broader internal zones.
• Review least-privilege rules at the segment boundary Check that each zone has explicit policies for who and what may cross it, and remove inherited permissions that let hosts or services move laterally by default.
• Build auditing into the segmentation design Require query, session, and command logging at the point where access crosses a segment, then verify the logs are sufficient to reconstruct who reached which system and why.
• Reduce policy load by collapsing similar resources Group systems with similar sensitivity and function so that the segment model stays understandable, reviewable, and sustainable for operations teams.

Key takeaways

• Network segmentation limits how far compromise can move, but only when the trust boundaries are clear enough to govern.
• Third-party access and over-privileged NHIs are the two highest-friction areas, because both turn segmentation into a policy problem as much as a topology problem.
• The practical goal is not more zones, but a smaller blast radius, better auditability, and access paths that are easier to defend than to abuse.

Key terms

• Network Segmentation: Network segmentation is the practice of dividing an environment into smaller trust zones so a compromise in one area does not automatically expose everything else. In identity terms, it limits how far a user, service account, or third party can move once access is granted.
• Blast Radius: Blast radius is the amount of damage a compromised identity or system can cause before containment stops it. In segmented environments, it is the practical measure of how far an attacker can travel, what data they can reach, and how many systems are exposed by one access decision.
• Third-Party Access Path: A third-party access path is the route vendors, contractors, or partners use to reach internal systems. It becomes a governance risk when the path is broader than the task, lacks clear isolation, or can be reused to move laterally into sensitive environments.
• Policy Explosion: Policy explosion happens when an environment has so many zones, rules, and exceptions that the access model becomes hard to understand and maintain. The result is often slower change management, more overlooked gaps, and weaker confidence in audit and enforcement.

Deepen your knowledge

Network segmentation, least privilege, and third-party access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to reduce blast radius across mixed human and machine access, it is worth exploring.

This post draws on content published by StrongDM: 7 Network Segmentation Best Practices to Level-up Your Security. Read the original.