Compliance and Insurance Impact

What happens when the hardware goes unsupported, per the frameworks that actually matter.

Regulatory frameworks

PCI-DSS 4.0

Payment Card Industry Data Security Standard. Requirement 6.3.3 says all system components must be protected from known vulnerabilities by installing applicable vendor security patches. Critical and high patches within one month of release, everything else within an organization-defined timeframe.

Operational consequence: once a device is past the vendor's security-support date, you can no longer meet 6.3.3 on that device. Ever. The standard's own guidance treats EoL software as a Req 6 and Req 5 (malware protection) failure unless you have documented compensating controls. QSA reports increasingly list "unsupported component" as a named finding with the SKU and the vendor EoL bulletin attached.

• PCI-DSS v4.0 Summary of Changes (PDF)

HIPAA Security Rule

45 CFR 164.308 governs administrative safeguards for electronic Protected Health Information (ePHI). The rule doesn't name "end of life" directly. It hits unsupported hardware through two requirements: 164.308(a)(1)(ii)(B) (implement security measures sufficient to reduce risks to a reasonable and appropriate level) and 164.308(a)(5)(ii)(B) (protection from malicious software).

Running EoL network gear that processes or transits ePHI is defensible only if your risk analysis documents the gap and your compensating controls (segmentation, EDR, limited access) actually reduce the risk. OCR settlements over the last decade repeatedly cite risk analysis failures around unpatched or unsupported systems. The rule is principle-based rather than prescriptive, which is easier to fail than a checklist.

• 45 CFR 164.308 (eCFR)
• HHS Summary of the HIPAA Security Rule

NIST SP 800-53 Rev 5

Two controls matter. SA-22 Unsupported System Components is the specific one: organizations must replace system components when vendor support (patches, firmware, replacement parts, maintenance contracts) is no longer available. SA-22 allows in-house or third-party support to fill the gap, but requires isolation of unsupported components from public or uncontrolled networks as a compensating control.

SI-2 Flaw Remediation is the general vulnerability management control. Requires installing security-relevant updates within an organization-defined window and integrating flaw remediation into configuration management. Once a device is EoL, SI-2 becomes structurally impossible to satisfy on that device, which throws the burden back onto SA-22.

FedRAMP and CMMC build on 800-53 and inherit these controls. If your organization handles Controlled Unclassified Information (CUI) under CMMC Level 2, SA-22 is in scope.

• NIST SP 800-53 Rev 5 (CSRC)
• SA-22 Unsupported System Components
• SI-2 Flaw Remediation

Cyber insurance underwriting

Underwriters stopped taking "we'll patch eventually" as an answer around 2021. Unsupported components now show up on virtually every renewal questionnaire. Two patterns to know about.

Renewal scrutiny

Expect questions about patching cadence, EDR coverage, MFA on remote access, and specifically whether you're running any EoL operating systems or hardware in production. "Yes, with compensating controls" is a valid answer if the controls are real and documented. "Yes, we're working on it" gets you a surcharge or an exclusion rider.

Claim denial patterns

Post-breach, the insurer reads the incident report, then checks your application. If a compromise traces to a CVE that was patched on the vendor's supported track but unavailable to you because the device was EoL, and your application said you patch critical CVEs within 30 days, that's a coverage issue. Carriers have denied claims for misrepresentation on this basis. Keep the application and the compensating-control documentation in sync with reality.

What specific carriers ask

Beazley lists minimum and optimal security controls in its buyer's guide. Unsupported systems isn't a line item by itself, but it collides with the controls that are: endpoint protection (can't run modern EDR on EoL OS), patch SLAs (can't patch if no vendor patches), network segmentation (becomes your only remaining answer).

Coalition actively scans for unpatched vulnerabilities and risky remote-access surfaces as part of underwriting. Unsupported perimeter hardware shows up in their scan.

• Beazley Cyber Insurance Buyer's Guide (PDF)
• Coalition: Underwriting Ransomware

Vendor milestone, compliance trigger

Which lifecycle milestone fires which compliance clock. See the terminology reference for what each term means at each vendor.

Compensating controls when you can't refresh yet

Sometimes the budget hits a wall before the EoL hits you. SA-22's own guidance and NIST SP 800-172 offer a reasonable compensating-control set that holds up in audit and at renewal:

• Network isolation. Unsupported component lives in a segment that can't reach public networks or other production zones. Documented firewall rules and an explicit deny-by-default posture.
• Enhanced monitoring. Additional logging and anomaly detection on the isolated segment, because you've lost the vendor's ability to patch attackable surfaces.
• Third-party support contract. A documented TPM or extended support agreement for replacement parts and failure-analysis coverage. Not a security-patch replacement, but required by SA-22 for the support-contract part of its requirement.
• Risk acceptance sign-off. A dated, named decision from someone with authority to accept the residual risk, tied to a refresh plan and timeline. Auditors and claims adjusters both want this document.

Compensating controls buy time. They don't buy permanent coverage. Every framework above assumes you're on a path to replacement.