Badge-system software will reach vendor end-of-life next fiscal year, and no replacement budget line exists. How should the security program treat this situation?
Select an answer to reveal the explanation.
Short Explanation
When the maker stops caring about your badge software, attackers do not. End-of-life without a budget line is a flashing yellow light for next year's breach report. Plan the replacement—or formally accept the risk—before support vanishes, not after the last patch ships.
Full Explanation
Badge-system software nearing vendor end-of-life with no replacement budget should be flagged as an asset-retention and security-planning issue requiring funded replacement or documented risk acceptance. Unsupported access-control software stops receiving patches while door hardware remains critical. Security programs must force the funding conversation—or formal risk acceptance—before support vanishes, not after the last patch ships.
Ignoring EOL because badges are physical objects fails by concept: the software that decides access is an intangible asset whose support status affects physical security. Disabling all door readers the day the EOL memo arrives without a transition plan fails as reckless availability harm to city facilities. Transferring ownership to the cafeteria vendor to remove the system from inventory fails as accountability theater that does not remediate unsupported software risk.
Exam caveat: EOL/EOS is an asset lifecycle risk that demands plan, budget, or formal acceptance—not denial. Operational check: enter EOL on the risk register, propose replacement funding in the next budget cycle, and if delayed, document compensating controls and official risk acceptance with a named owner.