Zero trust segmentation lessons from a small credit union team

At a glance

What this is: This is Illumio's account of how Spokane Teachers Credit Union's small security team drove Zero Trust segmentation to more than 90% enforcement through incremental rollout and executive support.

Why it matters: It matters because identity and access teams increasingly have to pair least privilege, segmentation, and operational governance across human, NHI, and workload environments.

By the numbers:

• 90% segmentation enforcement as part of their Zero Trust strategy.
• Small teams can move an app from 100% exposed to 40% protected and still make meaningful progress.

👉 Read Illumio's full account of STCU's Zero Trust segmentation journey

Context

Zero Trust segmentation is a governance problem as much as a technical one. The challenge is not simply placing controls in the network path, but making containment, ownership, and phased adoption visible enough for leadership to sustain it. For IAM and NHI programmes, that same pattern applies when access decisions, workload boundaries, and privileged paths need to be controlled incrementally rather than redesigned all at once.

For STCU, the practical question was how a lean team could make segmentation operational without overwhelming the business. Illumio presents the story as proof that small organisations can build resilience step by step, which is a familiar pattern in identity security as well. When teams cannot boil the ocean, they need a bounded rollout model, a clear control objective, and a repeatable way to prove progress.

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 do small security teams often succeed with Zero Trust when larger programmes stall?

A: Small teams can shorten decision loops, align more easily with leaders, and avoid overengineering early controls. They are also more likely to measure progress in practical increments, such as reducing exposure on a subset of applications. That makes the programme easier to sustain and easier to explain to the business.

Q: What breaks when Zero Trust is treated only as a technical project?

A: Controls become harder to adopt, exceptions multiply, and application owners see the programme as an obstacle rather than a shared operating model. Without business sponsorship, segmentation often stalls at the design stage or gets implemented unevenly. The result is fragmented enforcement that looks better on paper than it does in practice.

Q: How do organisations know whether segmentation is actually improving resilience?

A: They should look for measurable reductions in exposed paths, clearer ownership of application boundaries, and successful recovery tests that prove containment still works during failure. A useful signal is whether the team can move a workload from fully exposed to partially protected without creating new operational blind spots.

Technical breakdown

Segmentation enforcement as a staged control model

Segmentation enforcement is the point at which policy is actually applied, not just designed. In practice, teams often move from visibility to observation, then to partial enforcement, then to broader containment as they learn where business traffic and trust boundaries really sit. That staged model reduces change risk and gives operators room to tune exceptions before they become permanent. The key technical idea is that containment can be expanded without redesigning the whole network at once, which is why small wins matter.

Practical implication: build rollout stages that prove enforcement on a limited application set before you extend policy to higher-value systems.

Why Zero Trust depends on business process, not only tooling

Zero Trust fails when it is treated as a product deployment instead of an operating model. Segmentation requires asset ownership, application knowledge, change management, and leadership priority because policy decisions affect how teams work every day. That is why the most durable implementations combine technical controls with quarterly review cycles, service ownership, and exception handling. For identity teams, the parallel is obvious: access policy only works when the business accepts the control boundaries and the review process behind them.

Practical implication: align segmentation governance with business planning so policy changes are reviewed like any other operational initiative.

Assume-breach testing for resilience and recovery

The assume-breach mindset shifts planning from prevention only to containment plus recovery. Quarterly disaster recovery exercises and penetration tests expose gaps that are invisible in architecture diagrams, such as weak segmentation boundaries, unclear failover paths, or over-dependent application flows. This is a resilience pattern, not just a testing ritual. For environments with human identities, NHIs, and workloads, the same logic applies to privilege paths: if a compromise happens, the organisation needs to know what can still be isolated and what must be restored first.

Practical implication: rehearse containment and recovery together so segmentation assumptions are validated before an incident forces the issue.

NHI Mgmt Group analysis

Zero Trust segmentation becomes durable only when it is governed as a business operating model. STCU's story shows that technical enforcement improves when leadership treats cybersecurity as a tracked initiative rather than an isolated technical project. That governance framing is just as relevant to IAM and NHI programmes, where access policy fails if it is disconnected from business ownership. The practitioner conclusion is simple: segmentation, privilege boundaries, and review cadence need executive sponsorship, not just tooling.

Small, phased wins are the right control pattern when full redesign is not realistic. The article reinforces a pattern we see repeatedly in security transformation: teams gain credibility by proving partial protection first, then extending control scope. That approach is especially relevant to identity programmes where service accounts, workload identities, and privileged paths cannot always be remediated in one cycle. The practitioner conclusion is to define measurable containment milestones instead of waiting for a perfect rollout.

Assume-breach exercises are where Zero Trust assumptions become testable. Quarterly recovery testing and penetration tests are not side activities, they are the mechanism that reveals whether containment boundaries and recovery paths actually work under stress. For identity leaders, the lesson extends to NHIs and privileged access: if a credential or trust path is compromised, the organisation must already know what can be segmented, revoked, or restored. The practitioner conclusion is to test the control plane against failure, not just against policy intent.

Relationship-building is a control enabler, not a soft benefit. The article makes clear that self-service, training, and transparency reduced friction between IT and the business. That matters because Zero Trust, like IAM governance, breaks down when operators and application owners see controls as purely obstructive. The practitioner conclusion is to treat cross-functional adoption as part of the security design, especially where workloads, human access, and NHI controls intersect.

Incremental segmentation creates a measurable resilience ledger that leaders can govern. Once organisations can show progression from exposed to partially protected systems, they can make better prioritisation decisions about where to invest next. That concept is useful beyond networking, because identity and privilege programmes also need a visible ledger of reduction in exposure. The practitioner conclusion is to report control gains in business terms, not just technical deployment terms.

What this signals

Segmentation programmes increasingly fail or succeed on governance maturity, not on the sophistication of the control alone. When organisations can show leadership how containment improves in measurable steps, they are better positioned to extend the model into privileged access and workload identity. For teams managing both human and non-human access, the lesson is that policy rollout, exception handling, and recovery testing have to move together.

Zero Trust rollout now overlaps with NHI governance because many of the highest-risk paths are machine-to-machine. Service accounts, API keys, and workload identities are often the least visible parts of the environment, yet they sit directly inside segmentation and access decisions. The broader warning is that a programme can have strong network controls and still leave identity exposure unresolved.

Containment metrics should become board-level reporting, not just operational telemetry. A leadership team that can see how many applications moved from exposed to partially protected can make better prioritisation decisions and avoid false confidence. That kind of reporting is easier to sustain when it is aligned with identity lifecycle discipline and zero-trust architecture principles.

For practitioners

• Map segmentation to business initiatives Tie each Zero Trust rollout to a named business programme, owner, and review cadence so segmentation is tracked alongside other leadership priorities, not treated as a background security task.
• Start with smaller applications first Use low-complexity applications to validate policy design, exception handling, and operational handoffs before moving to higher-value systems that have more business impact if misconfigured.
• Measure progress as containment, not completion Track how much of the environment moves from fully exposed to partially protected, and use that delta to justify the next phase of control expansion.
• Rehearse breach containment with recovery tests Run disaster recovery exercises and penetration tests together so segmentation boundaries, restoration paths, and operational dependencies are all validated under realistic failure conditions.
• Build self-service and training for application owners Give peers enough context to understand blocks, exceptions, and policy changes so the security team can scale enforcement without becoming a bottleneck.

Key takeaways

• STCU's story shows that Zero Trust segmentation succeeds when it is managed as an enterprise programme, not a security side project.
• The most practical measure of progress is not perfection, but movement from exposed systems to partially protected ones.
• For identity teams, the lesson is that segmentation, access governance, and recovery testing need the same operational discipline.

Key terms

• Segmentation Enforcement: Segmentation enforcement is the point where access policy is actively applied to block or permit traffic between systems. It turns Zero Trust from a design intent into an operating control, and its value depends on accurate application mapping, exception handling, and ongoing tuning.
• 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.
• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

What's in the full article

Illumio's full blog covers the operational detail this post intentionally leaves for the source:

• The five interview-backed lessons from STCU's security lead on sequencing Zero Trust work in a lean team.
• The way the team built a repeatable playbook for smaller applications before expanding to more complex systems.
• The role of quarterly disaster recovery exercises and third-party testing in validating segmentation assumptions.
• The practical leadership dynamics behind getting business buy-in for segmentation as an enterprise initiative.

👉 Illumio's full post includes the interview context, rollout lessons, and the next step into Azure.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that supports broader identity programmes. It helps practitioners connect access control, lifecycle discipline, and operational resilience across human and non-human estates.