Zero Trust for federal agencies: Hypershield, ISE, and Secure Access explained

Key takeaways

• Zero Trust is now a federal deadline, not a philosophy. OMB M-22-09 and the DoD Zero Trust strategy set target dates, and agencies are measured against pillars covering identity, devices, networks, applications, and data.
• No single product is Zero Trust. Cisco Identity Services Engine handles identity and device posture, Hypershield enforces workload-level segmentation, and Secure Access replaces VPN with cloud-delivered access. They cover different pillars.
• ISE is the policy engine. It authenticates users and devices, profiles what connects, and pushes segmentation policy across wired, wireless, and VPN, which makes it foundational to STIG-compliant builds.
• Hypershield brings enforcement down to the workload and kernel level using eBPF, so east-west traffic inside the data center is segmented and patched without waiting on change windows.
• Secure Access converges ZTNA, secure web gateway, CASB, and firewall-as-a-service into one cloud edge, giving remote and hybrid federal staff identity-based access without backhauling traffic.
• Procurement is part of the architecture. SEWP, GSA, and partner contract vehicles determine how fast an agency can actually field these tools, so plan acquisition alongside design.

Zero Trust stopped being optional for federal agencies

For years, Zero Trust lived in conference keynotes and vendor slideware. That era is over. Executive Order 14028 and the follow-on Office of Management and Budget memo M-22-09 set explicit target dates for federal civilian agencies, and the Department of Defense published its own Zero Trust strategy with a target architecture and a 2027 horizon. The question facing most agency network teams is no longer whether to adopt Zero Trust. It is which architecture survives an inspector general audit and a STIG review at the same time.

The hard part is that Zero Trust is a model, not a SKU. It assumes breach, verifies every request, and grants the least privilege necessary, across five widely cited pillars: identity, devices, networks, applications and workloads, and data. An agency can buy a firewall and still fail a Zero Trust assessment if identity and segmentation are weak. That is why the federal alignment work maps controls back to frameworks like the NIST SP 800-53 catalog and validates configurations against the DISA STIG library. The framework tells you what good looks like; the products have to make it real.

• Identity: strong authentication and continuous verification of users and service accounts
• Devices: posture checks and inventory before anything touches the network
• Networks: microsegmentation so a breach in one zone does not become a breach everywhere
• Applications and workloads: per-workload enforcement and least-privilege access
• Data: classification and protection that follows the data, not the perimeter

The three Cisco pieces, and what each one actually does

When agencies ask us to map Cisco's portfolio to the Zero Trust pillars, three names come up constantly: Identity Services Engine, Hypershield, and Secure Access. They are frequently mentioned in the same breath, which leads people to assume they overlap. They do not. Each addresses a distinct pillar, and a defensible architecture usually uses all three together rather than picking one.

Think of it as a division of labor. Identity Services Engine answers who and what is allowed on the network. Hypershield answers what a workload is allowed to do once it is inside, down to the kernel. Secure Access answers how a user reaches an application when they are nowhere near the building. Cisco's broader security portfolio is large, but for federal Zero Trust these three carry most of the weight. On our own security practice page we break down how they slot into FISMA-aligned and DoD builds, and our defense team handles the classified and STIG-heavy variants.

Cisco Identity Services Engine: the policy engine for identity

Identity Services Engine, almost always called ISE, is the part most directly tied to the identity and device pillars. It authenticates users and endpoints, profiles every device that asks to connect, and enforces network access policy across wired ports, wireless, and VPN from a single place. In a Zero Trust context, ISE is what turns a vague principle like verify everything into an actual access decision at the switchport. Nothing gets an IP and a path to sensitive systems until ISE has checked identity and posture.

For federal teams, the device side matters as much as the user side. An agency network is full of things that are not people: printers, cameras, building automation, medical devices, industrial controllers. ISE profiles them, assigns them to the right segment, and keeps the unknown and the noncompliant in a quarantine zone. That profiling capability is why ISE shows up so often in STIG-compliant and DoD designs, where an unmanaged device on the wrong VLAN is a finding waiting to happen.

ISE is also the engine behind software-defined segmentation. Instead of hand-editing access lists on dozens of switches, you define group-based policy once and ISE distributes it. That dramatically shrinks the blast radius of a compromised endpoint, which is the entire point of the networks pillar. Our Identity Services Engine page covers the licensing tiers and deployment models, and our lifecycle services team handles the version upgrades that ISE deployments inevitably need.

Cisco Hypershield: enforcement at the workload and kernel

Hypershield is the newest of the three and the one that confuses people most, partly because it does not look like a traditional appliance. It is a distributed security architecture that pushes enforcement directly into the data path of workloads, using eBPF in the Linux kernel and programmable hardware where available. In plain terms, it lets you segment and protect east-west traffic inside the data center at the level of the individual workload, not just at a chokepoint firewall on the way in.

This solves a problem that has dogged federal data centers for a decade. Perimeter controls are strong, but once an attacker is inside, lateral movement between workloads is often wide open. Hypershield enforces least-privilege between workloads and can apply a compensating control or virtual patch the moment a vulnerability is disclosed, without waiting for a maintenance window or a full application owner sign-off cycle. For agencies that take patch latency seriously, that autonomous segmentation and shielding is the headline feature.

Hypershield does not replace ISE, and it does not replace the firewall. It complements both. ISE governs who gets onto the network, the Cisco Secure Firewall family governs north-south traffic at the boundary, and Hypershield governs what happens between workloads once traffic is already inside. We cover where it fits in modern fabric on our data center page, and the firewall side of the story is grounded in the published Secure Firewall 3100 Series data sheet.

Cisco Secure Access: Zero Trust for the workforce that left the building

The third pillar most agencies struggle with is access for people who are not on the network at all. Remote staff, contractors, and hybrid employees used to ride a VPN that dropped them onto the internal network with broad reach. That model is the opposite of Zero Trust. Cisco Secure Access is the answer here: a cloud-delivered security service edge, or SSE, that converges Zero Trust Network Access, a secure web gateway, a cloud access security broker, and firewall-as-a-service into a single service.

The practical difference is that Secure Access grants a user access to a specific application based on identity and device posture, not access to a subnet. A contractor who needs one case-management system gets exactly that, and nothing adjacent. Traffic does not backhaul through a regional data center, which improves performance for a distributed federal workforce while keeping policy consistent whether the user is on-site, at home, or on travel.

Because it is identity-driven, Secure Access pairs naturally with ISE: the same identity that governs in-building access can govern remote access, which keeps your policy story coherent across an audit. It also reduces the legacy VPN attack surface that has produced so many recent advisories. We walk through SSE migration on our security services page, and tie it into broader connectivity decisions on our SD-WAN page for agencies modernizing the branch at the same time.

How the three fit together in one architecture

A common mistake is treating these as competing options and choosing one. In a real federal deployment, they layer. Picture a clinician at a VA facility connecting a tablet on-site: ISE authenticates the device, checks posture, and places it in the correct segment. The same clinician working from home reaches the EHR through Secure Access, which verifies identity and grants access to that one application. Inside the data center, Hypershield ensures the EHR workload can only talk to the database it is supposed to talk to, and nothing else.

That layered model is what auditors want to see, because it covers multiple pillars with overlapping enforcement rather than a single line of defense. It is also why we rarely sell these as standalone purchases. The design work is in the policy: defining the segments, the group-based access rules, and the application mappings so that the three tools reinforce each other instead of creating conflicting rules. Our network and security design service exists specifically for that policy modeling phase, and our managed operations team runs the day-two tuning once it is live.

Healthcare is one example, but the same pattern applies across mission spaces. We document vertical-specific builds on our government industry page, where the constraints around classification, FedRAMP, and continuous monitoring shape which features matter most. The architecture is consistent; the emphasis shifts with the mission.

Procurement and lifecycle: the part that decides your timeline

The fastest way to derail a Zero Trust program is to design it without thinking about acquisition. Federal teams cannot simply buy off a website. The vehicle matters: many agencies field this kind of gear through NASA SEWP or through GSA schedules, and Cisco maintains its own federal contract and funding vehicle resources to map products to those paths. Choosing the contract vehicle early can shave months off a deployment, and choosing it late can blow a fiscal-year deadline.

Lifecycle is the other half. Zero Trust is not a one-time install. ISE needs version maintenance, Secure Access policies evolve as applications move, and the underlying switching and firewall hardware carries its own support and end-of-life timeline you have to track against the Cisco end-of-life policy. Keeping support current through Smart Net Total Care is not optional in a security architecture, because an unsupported control is a control you cannot defend in an audit. We handle vehicle selection and quoting on our procurement page, and you can start a scoped build with our team through the request a quote form.

• Pick the contract vehicle before final design, not after, so acquisition does not stall delivery
• Track end-of-life dates for switching, firewalls, and ISE nodes against your Zero Trust roadmap
• Keep Smart Net Total Care current; an unsupported security control is an audit liability
• Budget for day-two operations, because policy tuning is continuous, not a launch task

A pragmatic starting point for agency teams

If your agency is early in its Zero Trust journey, you do not have to field all three tools at once. Most successful programs sequence the work. Identity tends to come first, because almost every other pillar leans on it, which makes ISE a natural anchor for the first phase. Once identity and device posture are solid, segmentation through Hypershield and remote access through Secure Access become far easier to enforce because the identity foundation is already there.

The sequencing should follow your own risk picture and your mandate deadlines, not a generic playbook. A DoD program racing a 2027 target architecture will prioritize differently than a civilian agency early in its M-22-09 milestones. What stays constant is the principle: verify explicitly, enforce least privilege, and assume breach at every layer. The Cisco tools are the means, but the architecture and the policy are what pass the audit. If you want a second set of eyes on where to start, our networking practice and security team regularly run Zero Trust readiness reviews tailored to a single agency's posture and contract vehicle.

Cisco products involved

• Cisco Hypershield
• Cisco Identity Services Engine (ISE)
• Cisco Secure Access (SSE)
• Cisco Secure Firewall
• Cisco Catalyst switching
• Cisco SD-WAN

Bottom line: Zero Trust for federal agencies is a layered build, not a single purchase: ISE for identity, Hypershield for workload segmentation, and Secure Access for the remote workforce, all tied to the right contract vehicle. Request a scoped Zero Trust quote and we will map the architecture to your mandate and acquisition path.