Zero trust segmentation lessons from a small credit union team

At a glance

What this is: Illumio profiles how STCU’s five-person security team reached more than 90% segmentation enforcement by sequencing Zero Trust work into smaller applications first.

Why it matters: For IAM and security leaders, the takeaway is that segmentation succeeds when it is governed as a business programme with repeatable controls, not as an isolated technical project.

By the numbers:

• STCU says its five-person security team reached more than 90% segmentation enforcement.

Context

Zero Trust segmentation is the practice of limiting east-west movement so that compromise does not automatically become a full-environment incident. The article shows that the hardest part is rarely the technology alone. It is the governance work of sequencing rollouts, securing leadership support, and making enforcement practical for a small team.

For IAM practitioners, the identity bridge is clear: segmentation only works when access decisions, enforcement points, and operating discipline stay aligned across human admins, workloads, and non-human services. STCU’s approach is a reminder that Zero Trust often fails when organisations treat it as a tool deployment instead of an operating model.

The article is a case study rather than a universal blueprint, so some elements are specific to a regional credit union’s size and risk appetite. Even so, the core pattern is typical of successful Zero Trust programmes: start narrow, prove value, then expand with repeatable controls.

Key questions

Q: How should security teams roll out Zero Trust segmentation without disrupting the business?

A: Start with a small, low-risk application set, define clear ownership, and use phased enforcement so the team can learn how policy behaves before expanding it. The safest path is usually incremental containment, not wholesale redesign. That approach reduces change risk, builds confidence, and creates evidence for leadership that the programme is working.

Q: Why does segmentation fail when it is treated as a purely technical project?

A: Because enforcement only works when business owners, application teams, and security teams agree on where boundaries belong and how exceptions are handled. Without that governance, policy decisions become inconsistent, support becomes reactive, and the control never matures beyond a one-off configuration exercise. Segmentation is effective when it behaves like an operating model, not a firewall rule set.

Q: What are the signs that a segmentation programme is actually maturing?

A: You should see repeatable rollout patterns, clear ownership of enforcement decisions, fewer informal exceptions, and the ability to move from small applications to more complex ones without starting over. If each policy rollout feels custom, the programme has not yet become operationally mature. Mature segmentation looks boring because the process is now predictable.

Q: What should teams do when segmentation blocks or testing expose gaps in resilience?

A: Treat the gap as a control design issue, not an isolated incident. Revisit the application boundary, the exception path, and the recovery procedure together, then retest until the same path can no longer bypass the intended enforcement point. If the control fails in recovery, it is not complete in production.

Technical breakdown

Why segmentation enforcement becomes a governance problem

Segmentation is often described as a network or firewall control, but its real challenge is governance. Enforcement policies must map to business applications, operational owners, and acceptable exception handling, or the programme stalls in review cycles and ad hoc approvals. In practice, the control only becomes durable when teams can explain why a block exists, who owns it, and how exceptions are tested and removed. That makes segmentation as much an operating discipline as a technical boundary.

Practical implication: define business ownership and exception handling for every segmentation policy before expanding scope.

Why small applications create safer Zero Trust learning cycles

Starting with smaller applications reduces the blast radius of mistakes while teams learn how policy design, change management, and user support interact. This is especially important where enforcement errors can interrupt critical services or undermine trust in the programme. By proving the process on lower-risk systems first, teams build a playbook that can be reused when moving to more complex applications. The mechanism is incremental maturity, not a big-bang architecture change.

Practical implication: use lower-risk application groups to validate policy design, rollback processes, and support workflows before tackling core systems.

How assume-breach testing validates segmentation

Assume-breach thinking turns segmentation from a static control into a resilience test. Quarterly disaster recovery exercises and third-party penetration tests help verify whether blocked paths, service dependencies, and recovery procedures behave as expected under pressure. In Zero Trust terms, the point is not just to prevent initial access but to limit lateral movement and confirm that controls still function during recovery. Without testing, segmentation can look complete on paper while leaving hidden paths open in practice.

Practical implication: test segmentation policies under recovery and adversary scenarios, not just during normal operations.

Threat narrative

Attacker objective: The attacker objective is to move laterally from one compromised system into broader internal resources without being stopped by segmentation boundaries.

1. Entry is constrained by segmentation policy, so an attacker who gains a foothold should not automatically reach adjacent systems or applications.
2. Escalation is limited when enforcement boundaries prevent unrestricted east-west movement and force access through defined control points.
3. Impact is reduced because compromised access stays closer to the initial application rather than spreading across the environment.

Breaches seen in the wild

• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust segmentation only scales when it is managed as a business control, not a technical afterthought. STCU’s story shows that leadership cadence, business prioritisation, and operational ownership matter as much as policy design. The governance lesson is that segmentation needs executive sponsorship and measurable milestones, or it becomes a stalled infrastructure project. Practitioners should treat it as an operating model decision.

Small application rollouts are a governance tactic, not a compromise. Starting with smaller systems creates a controlled learning environment where teams can validate enforcement logic, support processes, and exception handling before moving to critical services. That sequencing reduces the chance that one early failure poisons organisational confidence. Practitioners should use low-risk segments to build repeatable playbooks.

Assume-breach validation is the difference between theoretical containment and real containment. Disaster recovery exercises and penetration tests expose whether segmentation policy actually survives stress, dependency failure, and user workarounds. This is where the identity bridge matters: human admins, service accounts, and application flows all need boundaries that still function during incident conditions. Practitioners should test enforcement under compromise conditions, not just steady-state operations.

Leadership buy-in is a force multiplier for segmentation maturity. The article makes clear that lean teams can only sustain Zero Trust when the programme is understood as shared organisational risk management. That insight aligns with NIST CSF governance expectations and with Zero Trust architecture thinking, where continuous enforcement depends on persistent accountability. Practitioners should align segmentation goals with leadership reporting and business risk language.

Zero Trust success is increasingly about operational repeatability, not initial deployment effort. The named concept here is segmentation habit formation: the point at which policy creation, testing, and adoption become routine enough that the organisation can scale without heroic effort. That is the real maturity signal. Practitioners should measure whether the control can be repeated safely across environments.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Segmentation programmes succeed when they are run like governed change programmes. The article points to a familiar pattern: smaller initial wins create confidence, but the durable gain comes from repeatable policy operations and executive sponsorship. For practitioners, that means the unit of progress is not the number of rules written, but the number of application boundaries that can be enforced, explained, and sustained.

Segmentation habit formation is the real maturity milestone. Once policy creation, testing, and exception handling become routine, the programme can move from pilot mode into repeatable expansion. That matters for IAM and security teams because the same governance logic can later support workload access boundaries, privileged admin paths, and controlled service-to-service communication.

The article also reinforces a Zero Trust baseline that is already widely accepted in identity programmes: properly managing NHIs is essential to a successful Zero Trust implementation, according to the Ultimate Guide to NHIs. For teams extending segmentation into cloud and workload environments, that means machine identities cannot be left outside the governance model.

For practitioners

• Treat segmentation as a business initiative Put segmentation on the same governance cadence as other quarterly business priorities, with leadership sponsorship and measurable milestones. Make ownership explicit so policy decisions are not left as ad hoc technical work.
• Start with smaller applications first Use low-risk applications to validate segmentation policy design, exception handling, and user support before moving to core services. Capture the playbook so later rollouts reuse the same control pattern.
• Build a repeatable enforcement playbook Document how blocks are approved, tested, communicated, and rolled back so the team can apply the same process across multiple application tiers. Repeatability matters more than one-off enforcement wins.
• Test containment through recovery exercises Include segmentation assumptions in disaster recovery exercises and third-party penetration tests so you can see whether blocked paths, dependencies, and recovery flows hold up under stress.
• Use leadership reporting to sustain momentum Report segmentation progress in business terms such as reduced exposure, fewer reachable paths, and improved resilience. That framing helps keep support in place when the programme reaches harder applications.

Key takeaways

• A small credit union team proved that segmentation can scale when it is governed as a business programme rather than a standalone technical project.
• Starting with smaller applications creates a safer path to Zero Trust maturity because teams can validate enforcement, exceptions, and recovery before moving to core services.
• The decisive control is repeatable containment, supported by leadership buy-in, tested boundaries, and operational discipline across both people and machine access.

Key terms

• Zero Trust Micro-Segmentation: A Zero Trust approach that divides the environment into small policy zones so workloads, users, and endpoints only communicate when explicitly allowed. It shifts protection from the perimeter to the application and workload layer, where trust is continuously constrained by policy rather than assumed by network location.
• Microsegmentation: A network control approach that divides environments into small security zones with explicit rules between them. Its purpose is to limit lateral movement and reduce blast radius when an identity, workload, or device is compromised.
• East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.
• Assume-Breach Model: The assume-breach model is a security stance that treats initial compromise as possible and focuses on detecting, constraining, and disrupting attacker movement after entry. It shifts attention toward visibility, containment, and response quality rather than relying only on perimeter prevention.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that complements broader Zero Trust work. It helps security and identity practitioners connect segmentation, access control, and identity governance across modern environments.