Cisco ISE support and deployment, starting with which version you're actually on
Trusted by
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.
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.
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.
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.
Does Cisco ISE work the same way in every industry?
No. The Cisco ISE work is the same craft in every sector, but the conditions around it are not. In manufacturing that means production lines that can't stop for a patch window; in energy and mining, SCADA networks and remote sites that can't go offline; and in healthcare, provincial health privacy law. We keep the service and change the part that bends.
Network access control for devices that can't run an agent.
OT and IT convergence. A flat network between plant and office is the common failure, and segmentation is the fix. It's a design problem, not a purchase.
SCADA networks and remote sites can't go offline, so changes are planned around them.
SCADA and ICS. Availability outranks confidentiality here, and you often can't take a system offline to investigate what happened on it.
Health information sits under provincial privacy law, and your IT provider is usually the custodian's agent.
PHIPA. Ontario's health privacy act, with its own definition of a custodian and its own duties for the agents acting on a custodian's behalf. Your IT provider is usually an agent.
Solicitor-client privilege decides how a firm can handle its data.
Law Society obligations. Confidentiality and competence duties reach the technology you practise with, and the vendors who touch client information. The firm is expected to have assessed the provider, which means the provider should arrive with the answers.
Protected A, B and C data handling decides where the work can run and who can touch it.
Protected A, B and C. Each level changes where the data can physically live, who can reach it, and what you have to prove about both. Most files turn on Protected B, and most disagreements turn on what counts as reaching it.
What do you need from Cisco ISE?
Tell us who you are and what you're working on. A senior engineer reads your message before replying, so the first answer is a real read on scope, risk and timing, within an hour, 24/7. Nothing here is a commitment, and we'll tell you plainly if we're not the right fit.
Your request
- Service
- Cisco ISE
What happens next
- A senior engineer replies within an hour, 24/7, never an SDR.
- We book a 30-minute call to listen, sketch options, and flag risks.
- You get a scoped statement of work within 3 business days.
Call the 24/7 line
+1 514-465-1584Cisco 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.
Want a Senior IT Consultant's Read on Your Setup?
Tell us what you run today and what keeps breaking. A senior SMEnode engineer replies within an hour with a first read on scope, risk and timing. No sales handoff.
Request a consultHow 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.
Engagement phases
Phases 01 to 04
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.
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.
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.
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.
Cisco ISE questions, answered straight.
Answers first, including whether this platform still has a future. An architect takes the call, not a salesperson.
Where this work connects.
These disciplines share the same senior team and tend to land together. Follow the thread to the next one.
- SupportCisco ACICisco ACI support and migration for Canadian data centres, from a team that holds the CCIE.
- SupportCisco SupportCanadian Cisco support from a CCIE-led team: what's actually covered, escalation past TAC, and licensing that stops surprising you.
- SupportPalo Alto SupportCanadian Palo Alto firewall support from a CCIE-led team, including the renewal nobody forecasts.
