32 / 33Cisco ISE

Cisco ISE support and deployment, starting with which version you're actually on

Canadian Cisco ISE deployment and support: version and patch state first, then policy, posture and guest access.

Talk to an architectSee what's covered
  • CCIE Security-led ISE work
  • Deployment, patching and rescue
  • Canadian data residency available
THE WORK

Cisco ISE support and deployment, three pillars, one operator.

One Canadian team establishes what you're running, builds a fallback, and only then changes policy. Identity Services Engine is a lifecycle problem before it is a policy problem.

  1. 1

    Version, advisories and lifecycle

    Which release, which patch, which advisories are still open per node, and a costed route off 3.1 or 3.2 before the order window closes. We also read what you pay per serial, because the contract position and the technical one rarely tell the same story.

  2. 2

    Policy a person can read

    Authentication, authorisation and profiling rules a new engineer can follow without a guide. When something breaks, the engineer on the call reads the running config instead of asking you to upload it again.

  3. 3

    Fallback, posture and guest

    A tested fallback for the day a node goes down, plus compliance checks and guest access that don't turn into a permanent helpdesk queue.

THE PROOF

Built to last. Evidence over promises.

Two Cisco ISE flaws scored CVSS 10.0 in 2025, and exploitation surged again in February 2026. Version tracking on a platform that authenticates every device you own isn't paperwork.

IN PRODUCTION

A Canadian estate that survived the patch.

We didn't know which patch level we were on, which tells you everything. SMEnode found us three patches behind on a release going off the price list, built a documented fallback, then upgraded over two weekends. Nobody in three buildings noticed.

SMEnode · Engineering principle
  • CCIE Data Center
  • CCIE Security
  • CCDE Design
  • Canadian data residency
THE DEEP DIVE

Cisco ISE support and deployment in Canada, made real.

I run this practice, so this is written by the engineer who'll read your policy sets, not a product page.

Start with the patch level, not the policy set.

Ask a Cisco Identity Services Engine administrator which patch level they're on and watch the pause. That pause is why this page starts where it does. In 2025 two ISE flaws were scored CVSS 10.0, both allowing unauthenticated remote code execution with root privileges, and CISA placed the first in its Known Exploited Vulnerabilities catalogue with a 2025-08-18 remediation date (source: CISA, 2025). Cisco then noted something most operators missed: patching those two does not cover CVE-2025-20337, which needs ISE 3.3 Patch 7 or ISE 3.4 Patch 2 (source: Cisco). Exploitation surged again from 2026-02-23. A platform that authenticates every device you own is not a good place to be three patches behind.

Where the risk actually sits.

Risk sits in three predictable places. Authorisation rules nobody can trace, because policy sets accumulate and each one was urgent at the time. A deployment with no tested fallback, so a single node failure stops authentication for a whole building at nine in the morning. And posture rules written for a device fleet that has since changed twice. None of that is found by opening a case and waiting. It's found by reading the configuration that's running, which is the part of support most people never get.

The lifecycle is a purchasing deadline, not a cliff.

ISE software 3.1 and 3.2 reach end of sale with 2026-11-03 as the last day to order, and the ISE Passive Identity Connector carries its own end-of-sale notice (source: Cisco). Active contracts keep TAC support, so the deadline is a purchasing one. That makes it a contract question as much as an engineering one, which is why we audit the entitlement per serial and hand you the version inventory an emergency directive will ask for. Search interest in this whole category is falling, and quieter search does not mean fewer deployments. It means fewer people learning the platform while the same Canadian estates keep running on it.
Spine-leaf fabric
THE METHOD

How our Cisco ISE deployment and policy work runs.

Four steps, and the first two happen before anybody touches a policy set. We've been called into enough broken Canadian deployments to know the order matters: a policy change on an unpatched cluster with no tested fallback is how a Monday morning turns into three buildings of people who can't log in. Establish the ground truth, build the safety net, then change things.

  1. Step 01

    Establish the ground truth

    Release and patch level per node, deployment model, licence position, open advisories against what's running, and whether the last backup has ever been restored.

  2. Step 02

    Read the policy sets

    Every authentication and authorisation rule in order, plus any TrustSec tags in use, with rules that never match flagged and the unexplainable ones listed for a decision.

  3. Step 03

    Build the fallback

    A documented, tested path to keep authentication running when a node goes down, agreed with the network team before any change is scheduled.

  4. Step 04

    Then change things

    Patch or upgrade, retire the dead rules, roll 802.1X, posture and guest access out in stages, and hand over runbooks your team can follow at 3am.

QUESTIONS

Cisco ISE questions, answered straight.

Answers first, including whether this platform still has a future. An architect takes the call, not a salesperson.

Nothing single, and it's Google's second most asked question about the platform. Cisco has folded ISE into its Zero Trust Access story alongside Secure Access, Duo and ThousandEyes, where it stays the identity and enforcement piece rather than a product being retired. Customers with active contracts keep TAC support. What is ending is specific software versions, which is a different and solvable problem.

Urgent for two unrelated reasons. 2026-11-03 is the last day to order 3.1 or 3.2, so the licensing route closes before the technical one does. Separately, if you're behind on patches you may still be exposed to flaws scored 10 out of 10 that attackers picked up again this February. We'll tell you which of the two is driving your timeline, because the answer changes the plan.

Sometimes, and we'll say so. ISE rewards organisations with a real identity source, a switch estate that supports the enforcement, and somebody who owns policy. Without those three, a smaller platform will serve you better and cost less to run. Where it earns its licence is a mixed estate with contractors, wired and wireless, and a compliance driver. We assess honestly before quoting.

Three separate costs, and only one is ours. Cisco charges by licence tier and endpoint count, and the tier you need depends on whether you want posture and profiling or just authentication. Infrastructure comes next, since redundancy needs more than one node. Our fee covers design, deployment and the runbooks. We take no margin on licences, so the sizing advice has nothing riding on it.

Yes, and it's most of what we do. We start by reading what's actually running: release and patch level per node, the policy sets in order, and the advisories still open against your version. You get that written up before we quote ongoing support, so you're buying against a known state rather than a hopeful one.

When there's no owner for policy inside the business, because access decisions are business decisions and an external team can't make them for you. When your switch estate can't enforce what you'd write, which we'd find in week one anyway. And when a network refresh is already funded, since the enforcement points are about to change and you'd design the policy twice.

LET'S CONNECT

Ready to build a stronger,
smarter network?

Explore our servicesBook a free consultation

A senior engineer replies within an hour, 24/7.