A vendor ends security support for a middleware stack still running in a county integration tier. Why is continuing without a plan unacceptable?
Select an answer to reveal the explanation.
Short Explanation
No more security patches means new holes stay open—like a lock manufacturer that will never send replacement pins. EOS is a forced decision point: upgrade or compensate.
Full Explanation
End-of-support means the vendor no longer supplies security fixes, leaving known and future vulnerabilities unaddressed on middleware still running in a county integration tier. Continuing without a plan is unacceptable because exploitability rises while patching stops; upgrade or compensating controls are required lifecycle actions to protect upstream and downstream municipal systems that exchange data through that tier.
Unsupported software does not automatically become compliant with audit frameworks—often the opposite. Security support endings affect production APIs, not merely marketing websites. Low CPU utilization is irrelevant to whether security updates are available.
Exam caveat: EOS/EOL require documented risk treatment: upgrade, replace, isolate/compensate, or formally accept with time bounds. "We’ll watch it" without controls is not a complete answer on exams.
Operational check: confirm the vendor’s EOS date and affected versions, scan for exposed CVEs, schedule upgrade or replacement, and if delayed, apply WAF/segmentation/strict IAM compensating controls with an expiration date. Report residual risk to county security governance until resolved.
In county integration operations, record the EOS date, chosen treatment, and compensating-control expiry in the lifecycle risk register so auditors and future on-call engineers can see why an unsupported middleware stack was temporarily retained and when that exception must end for connected civic services.