What happens when an organisation keeps using Pulse Connect Secure after end of support?

Once a product reaches end of support, it no longer receives code changes or security fixes, so any newly discovered vulnerability remains unresolved. For Pulse Connect Secure 9.1x, that means affected devices cannot be patched for CVE-2025-22457. The practical consequence is persistent exposure, which forces migration planning instead of patch-based remediation.

Why End-of-Support Changes the Risk Picture for Pulse Connect Secure

end of support is not just a procurement milestone. It changes the security model because the vendor has stopped providing the fixes, validation and product maintenance that keep newly found issues from becoming permanent exposure. For remote access appliances such as Pulse Connect Secure, that matters because the device is often placed at a high-trust boundary and exposed to the internet, so an unpatched flaw can remain reachable until the platform is removed or replaced. Security teams should treat this as a lifecycle risk, not a one-off patching delay.

When organisations continue to depend on a retired remote access product, they inherit a control gap that cannot be closed with normal vulnerability management. In practice, many security teams encounter the real impact only after an exploit or disclosure has already made the unsupported version impossible to justify.

What Staying on Unsupported Pulse Connect Secure Means Operationally

The practical issue is that support status changes the remediation path. While the product is still supported, a new vulnerability can usually be handled through a vendor fix, a compensating control, or an upgrade within the same family. After end of support, that option disappears. The organisation can still try to reduce exposure through isolation, tighter access rules, monitoring, and accelerated migration, but those measures only reduce risk; they do not restore product security.

That distinction matters because remote access gateways do more than terminate sessions. They typically sit in front of authentication, network access, and internal resource entry points, which means their weakness can affect confidentiality, availability and trust. If the appliance is exposed to the public internet, the consequence of continued use is not limited to the single known flaw. It also includes the likelihood of accumulating unresolved weaknesses as additional vulnerabilities are discovered over time.

For practitioners, the key operational question is whether the system can still be governed safely during a short transition period. If the answer depends on assumptions such as perfect segmentation, no direct internet exposure, or flawless monitoring, the organisation is relying on controls that may be brittle under stress. External guidance on control baselines, such as NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful here because it reinforces that a control is only effective when it remains enforceable over the asset’s full lifecycle.

Plan for unsupported Pulse Connect Secure as a time-limited exception, not a steady-state design.
Assume patch-based remediation is no longer available and confirm what compensating controls actually reduce exposure.
Validate whether the appliance is internet-facing, because external reachability materially increases the risk of unsupported use.
Track migration progress as a security action, not just an infrastructure project.

The guidance breaks down when the organisation cannot isolate the device or when it must remain exposed for business continuity, because at that point the residual risk is usually too high to treat as manageable.

Common Exceptions, Temporary Workarounds and Migration Gaps

Tighter containment often increases operational overhead, requiring organisations to balance continuity against the fact that unsupported software cannot be made current again. That tradeoff is real, especially where migration depends on identity federation, remote workforce access or legacy integration constraints.

There is a difference between short-term containment and false confidence. A heavily restricted unsupported appliance may be acceptable for a brief transition window if access is narrow, logging is strong and a replacement date is committed. It is much harder to defend when the product remains in service because of budget delay, integration fatigue or an assumption that “nothing has happened yet.” Security teams should also be careful not to confuse temporary isolation with true remediation. Once support ends, new vulnerability discovery becomes an enduring governance problem, not a patch cycle problem.

There is no consensus that unsupported remote access infrastructure can be treated as normal risk acceptance for long periods; the practical view is that compensating controls buy time, but only migration removes the structural exposure.

Risk and Threat Considerations

Unsupported remote access appliances create persistent exposure because any newly disclosed weakness remains unresolved and can sit at a perimeter trust boundary. That makes the asset attractive to attackers who look for internet-facing systems with known weaknesses, especially where the appliance mediates authentication or access into internal services.

Failure mechanism: The risk materialises when the product can no longer receive vendor remediation, leaving the organisation dependent on containment controls, exposure reduction and rapid replacement. If those controls are incomplete, an attacker can exploit the unpatched condition, gain access through the gateway, or use it as a foothold into downstream resources.

Impact: The likely consequence is prolonged compromise exposure rather than a single isolated defect. That can affect remote access availability, sensitive internal access paths, incident response complexity and the organisation’s ability to prove that the control environment remains supportable.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	7 — Continuous Vulnerability Management	Unsupported software leaves vulnerabilities unpatchable, requiring active tracking and removal.
	4 — Secure Configuration of Enterprise Assets and Software	Unsupported appliances often persist through weak configuration and exposure management.
Recommendation — Accelerate inventory-driven remediation and retire unsupported Pulse Connect Secure instances. Harden exposure, restrict access, and document compensating controls while migration proceeds.
NIST CSF 2.0	ID.AM-2 — Software and Assets are Inventory, Managed, and Governed	End-of-support decisions depend on accurate asset and lifecycle visibility.
	PR.IP-12 — A Vulnerability Management Plan is Developed and Implemented	End-of-support removes patch remediation, making planned replacement the key response.
	PR.AC-5 — Network Integrity Is Protected	Remote access gateways amplify exposure when they remain reachable after support ends.
Recommendation — Maintain a current inventory that flags unsupported remote access appliances for urgent retirement. Shift from patch response to replacement planning when vendor support ends. Limit reachability and segment unsupported access infrastructure as tightly as possible.

Practitioner Guidance

What to prioritise: Treat the unsupported appliance as a migration-risk item with security urgency, not as a routine infrastructure holdover. The immediate priority is to confirm how much exposure remains while the replacement is still pending.

Decision rule: If the device is internet-facing or mediates broad internal access, escalation should be immediate and the acceptable transition period should be short. If it is already isolated and tightly constrained, the remaining work is to prove that the containment is real rather than assumed.

What to verify: Confirm the exact version in use, the remaining user population, the access paths it enables, and whether compensating controls actually reduce attack surface. Teams often underestimate the difference between “limited use” and “limited exposure.”

Practitioner takeaway: Once support ends, the security question is no longer whether the product can be patched, but whether the organisation can remove dependency on it before exposure becomes an incident.