Running Cisco CPAR after end of life means operating an authentication layer that will never receive another security patch. Cisco officially ended support in October 2025. Every CVE disclosed since that date against CPAR’s code path is permanently unresolved. The exposure is not a future risk, it is a present one that compounds every month you stay on an unsupported platform. If your organization is still on CPAR, the question is no longer whether to migrate. It’s how to sequence the move before the exposure becomes a breach.
Before October 2025, the CPAR migration deadline was a planning problem. Now it’s a production problem. Most vendor content on this topic was written for operators who still had time to plan that content is stale. This post is written for operators who missed the window, or who inherited a network where someone else did.
What follows is an honest account of what running unsupported AAA infrastructure looks like in June 2026: the specific threat vectors, why the compatibility gap is widening faster than most architecture teams expect, and what a practical triage sequence looks like for a team that needs to move without disrupting live services.
What does Cisco CPAR end of life actually mean for operators still running it?
End of life means Cisco will no longer issue patches, fix CVEs, provide TAC support, or release software updates for CPAR. The platform does not stop working on the day EOL hits that is exactly what creates the false sense of safety. Authentication sessions keep completing. RADIUS transactions keep flowing. From the outside, nothing changes.
What changes is invisible: the security and compatibility gap begins widening from day one and never stops. Every month that passes without a vendor patch cycle is a month in which newly published CVEs against the platform’s dependencies go permanently unaddressed. Protocol support freezes while the rest of the network continues to evolve around it.
For operators in regulated markets, there is an additional and immediate problem: there is no longer a software maintenance record to show an auditor. CPAR’s EOL date is a matter of public record. Any auditor reviewing your security posture can look it up.
What are the specific security risks of running unsupported CPAR right now?
Three threat vectors deserve direct attention. They are not theoretical they are the attack patterns active against authentication infrastructure in carrier networks today.
1. No patch path for newly disclosed CVEs
The authentication layer is one of the highest-value attack surfaces in a carrier network. When a vulnerability is found in a library or component that CPAR depends on an OpenSSL version, a RADIUS stack, a Diameter library a supported platform issues a remediation within weeks. CPAR issues nothing. Cisco no longer maintains it.
This is not a static exposure. It compounds. The longer CPAR stays in production, the larger the unpatched CVE surface becomes. There is no mechanism to close it short of replacing the platform. Operators who have been running CPAR since October 2025 are now eight months into that accumulation.
Key Insight
According to NIST’s National Vulnerability Database, the average time between CVE disclosure and active exploitation in the wild is now under 15 days for high-severity vulnerabilities. An unpatched authentication platform does not stay theoretical for long.
2. Brute-force and credential-stuffing attacks go undetected
Modern AAA platforms detect brute-force and credential-stuffing attacks in real time by analyzing authentication failure patterns across concurrent sessions. CPAR was not built with this capability, and without a vendor patch cycle, it will never have it.
Credential stuffing using breached username/password lists to drive mass authentication attempts is among the most active attack vectors against subscriber infrastructure today. An authentication system that cannot detect anomalous login-attempt patterns cannot trigger SIEM alerts, rate-limit offending sources, or block IP ranges automatically. The attack succeeds or fails based entirely on whether the credentials work. The platform never notices either way.
3. Privilege-escalation exposure on TACACS+ device admin paths
Operators using CPAR for network device administration via TACACS+ face a specific and serious risk: privilege-escalation attacks targeting the command authorization path. TACACS+ controls which engineer can run which command on which device. A successful privilege-escalation attack on this path gives an attacker reach into network device configuration routing tables, ACLs, firewall rules under a session that looks like a legitimate administrator login.
Without policy-violation detection running over TACACS+ log streams, these attacks leave a minimal footprint. Standard upstream monitoring tools do not catch them reliably because the session itself authenticates successfully. Detection requires instrumentation at the AAA layer.
What compliance and regulatory exposure does unsupported AAA create?
For operators in regulated markets, running unsupported software is not purely a technical risk, it is an audit risk with direct organizational consequences. Frameworks including NIS2 (EU), DORA (financial-adjacent operators in Europe), and sector-specific telecommunications security regulations in the Middle East and Africa increasingly require evidence that security-critical software is actively maintained by a vendor.
When a CISO presents security posture to an external auditor, “our authentication platform reached end of life eight months ago and we have no active vendor patch schedule” is not a position that survives scrutiny. The documentation gap alone no security advisory feed, no maintenance history post-October 2025 creates an audit finding that is difficult to mitigate without platform replacement.
There is also an internal governance dimension. Most enterprise security policies require that all production software remain under active vendor support. If your organization has such a policy, CPAR is already out of compliance with your own rules. The longer it stays in production, the harder the conversation becomes at the next board-level security review.
How fast does the compatibility gap grow after EOL?
This is the issue that surprises most architecture teams. The security exposure is immediate and visible from day one. The compatibility gap is slower to become painful in production but it is not slow.
Modern network components ship on a release cadence CPAR cannot match. 5G standalone network functions, cloud-native broadband network gateways, and new EAP variants for Wi-Fi calling and offload all require AAA capabilities that assume the underlying platform is actively developed. Each time a vendor ships a revised Diameter interface, or the IETF ratifies a new EAP profile, or a 5G core function requires an updated S6a/S6b interaction CPAR falls further behind without any mechanism to catch up.
What begins as a minor gap in month one becomes a significant interoperability constraint by month twelve. Operators planning 5G SA buildouts, Wi-Fi calling deployments, or broadband network gateway upgrades will encounter this wall before they encounter the security wall. Both arrive. The compatibility wall typically arrives faster because it shows up as failed integration tests in a project, not as a breach.
The protocol areas where the gap is most acute:
- Diameter interfaces (S6a, S6b, SWx, SWm, Sh, Gx, Gy, Sd, STa) –evolving continuously with 3GPP 5G core specifications. CPAR cannot track these revisions without patches it will never receive.
- EAP family (EAP-SIM, AKA, AKA’, TLS, TTLS, PEAP)– updated security profiles and new variants require active platform development cycles.
- RADIUS with Dynamic Authorization and Change-of-Authorization (CoA)– increasingly required for live session management in fixed broadband and converged operator environments.
If your network roadmap includes any of these and most carrier roadmaps do the CPAR migration timeline is not discretionary. It becomes a hard dependency of other projects.
What should operators still on CPAR do right now?
Waiting for the perfect migration window is not a viable strategy when the platform is already unsupported. The triage sequence below is designed to reduce the highest-risk exposure first while a full migration is scoped and resourced.
Step 1: Map every CPAR-dependent authentication flow and rank by risk
Not every authentication flow carries the same exposure. A subscriber Wi-Fi RADIUS session is a different risk profile from TACACS+ device administration on your core routing infrastructure. Begin by cataloguing every service that authenticates through CPAR: what it authenticates, the volume of authentication attempts it processes, and what the authenticated entity controls if compromised.
Rank each flow on two axes: blast radius if the authentication path is compromised, and daily authentication volume (high-volume paths attract more attention from automated credential-stuffing operations). This map becomes the sequencing input for the migration plan.
Step 2: Prioritize the highest-risk paths for immediate migration planning
TACACS+ device administration paths and any authentication flow sitting in front of a regulated service or sensitive subscriber data should be at the front of the migration queue. These are the paths where a compromise carries the highest operational and regulatory consequence.
A sequenced migration is lower-risk than a big-bang cutover. Plan for parallel operation periods where CPAR and the replacement platform run concurrently for specific authentication domains while the new platform is validated against production traffic. This is standard practice in Tier-1 carrier migrations and can be scoped to minimize service disruption.
Step 3: Run a vendor evaluation against your real 5G and protocol requirements
The AAA replacement vendors actively pursuing CPAR migrations — Alepo, Enea, Kron, Radiator are not equivalent. The questions that differentiate them quickly:
- Does the platform cover the full Diameter interface set your 5G roadmap requires not just S6b and SWx but also Sd, STa, SWa, SWd, and the Gx/Gy charging interfaces?
- Is security instrumentation (brute-force detection, credential-stuffing detection, privilege-escalation detection, DDoS prediction, SIEM integration) built into the AAA stack, or is it a separate product requiring its own integration project?
- What is the vendor’s parallel-operation approach during migration? Can traffic be progressively shifted per authentication domain, or does the cutover require a maintenance window?
- What is the production track record at Tier-1 carrier scale under peak authentication loads?
Alepo AAA is in production at STC, Etisalat, and Vodafone operators where authentication downtime is not acceptable. Its AI Agent layer detects anomalous access patterns, brute-force and credential-stuffing attempts, privilege-escalation activity, and predicts DDoS conditions directly from RADIUS, Diameter, and TACACS+ log streams as part of the AAA stack, not as a separate integration. If you are at the vendor evaluation stage, the Alepo team can walk through a deployment architecture specific to your network topology and protocol footprint.
Frequently Asked Questions
What is Cisco CPAR end of life?
Cisco CPAR (Cisco Policy and Charging Application) reached end of life in October 2025. End of life means Cisco will no longer issue security patches, remediate vulnerabilities, provide TAC support, or release software updates. The software continues to function operationally, but any CVE disclosed after the EOL date will not be fixed. Running CPAR after end of life means running an authentication platform with a permanently growing unpatched attack surface.
Can I keep using CPAR after October 2025?
Technically yes, the software continues to operate. Whether doing so is acceptable under your organization’s security policy, your regulatory obligations, or your cyber insurance terms is a separate question. Most enterprise security policies require active vendor support for production security infrastructure. Most regulators in telecommunications markets expect evidence of software maintenance. Most cyber insurers are tightening requirements around end-of-life software. Each of those is a conversation your CISO and legal team need to have, not a purely technical decision.
What are the main alternatives to Cisco CPAR?
The major AAA replacement options actively targeting CPAR migrations are Alepo AAA, Enea, Kron, and Radiator. For a direct comparison across deployment model, protocol coverage, and migration approach, see the Alepo CPAR EOL transition guide. The right choice depends on your protocol footprint (RADIUS-only vs full Diameter), 5G roadmap, and deployment environment.
How long does an AAA migration from CPAR typically take?
Migration timelines vary based on the number of authentication domains, protocol complexity, and integration depth with BSS, PCRF, and HSS systems. A scoped migration of a single domain can complete in six to twelve weeks. A full carrier-scale migration across multiple access types and authentication domains typically runs six to eighteen months, with parallel operation periods built in for each domain. The variable that most affects total elapsed time is how early the vendor evaluation and architecture phase starts beginning that work now reduces the calendar pressure on every downstream step.
Does running CPAR post-EOL affect cyber insurance coverage?
This depends on your specific policy terms. Many enterprise cyber insurers now include clauses requiring that security-critical software be under active vendor support. End-of-life software on the authentication layer is the kind of finding that insurers can use to dispute a claim or increase premiums at renewal. It is worth having your broker review your policy terms against your CPAR deployment status before your next renewal date.
Talk to an AAA migration expert
If your network is still running Cisco CPAR, the right next step is a migration architecture review. Alepo’s engineers have run CPAR replacement programmes at Tier-1 carrier scale. Talk to an AAA migration expert.
Or explore the full capability overview at the Alepo AAA Server page.
