6. One product at several versions, the oldest unsupported

The same product is installed at more than one version and the oldest is past vendor security support (or on extended support only). The finding sits on each line at an unsupported version and names the newest version in the list, which is often already supported and so the quickest to move to.

When it is raised: two or more versions of one record in the list, the oldest past its security end date; raised on each line at a version past support or on extended support only
The question: Can the older installs move to the version already supported elsewhere in the estate, so one supported version remains?
For: your IT operations lead

The clauses it can cite

Cyber Essentials SU.1Software Licensed and Supported

Software Licensed and Supported. All software on in-scope devices must be licensed and supported by the vendor (i.e. receiving security updates). Unsupported software must be removed or segregated.

What an assessor asks to see: SCCM/Intune software inventory; EOL/EOSL register; Segregation evidence for unsupported

Where software lists usually fall short: Windows 7/Server 2012 still in use; EOL Java runtimes

Source: Cyber Essentials (NCSC and IASME), read 30 Sep 2026

CIS Controls v8 2.1Establish and Maintain a Software Inventory

Establish and Maintain a Software Inventory. Keep a detailed register of all licensed software installed across enterprise assets. Each entry has to capture the title, the publisher, the date of first installation or use, and the business reason for it; where it makes sense, also capture the URL, the app store or stores, the version or versions, how it is deployed, and the date it was retired. Revisit and refresh the register at least twice a year.

What an assessor asks to see: Software inventory export showing title, publisher, first install date and business purpose for each licensed title; Record of the twice-yearly inventory review; Software asset management standard naming the mandatory inventory fields and the register owner; Sample of software titles traced from endpoints to the register showing publisher and business purpose recorded; Retired software entries showing a decommission date rather than being deleted from the register

Where software lists usually fall short: Register covers workstations but omits servers, cloud workloads or SaaS subscriptions; Business purpose field left blank or filled with a generic value for most titles; Twice-yearly review not held, so the register still lists software removed long ago

Source: CIS Controls v8 (Center for Internet Security), read 30 Sep 2026

CIS Controls v8 2.2Ensure Authorized Software is Currently Supported

Ensure Authorized Software is Currently Supported. Only software that still receives vendor support may be marked as authorised in the enterprise software register. Where unsupported software is still needed for the mission, record an exception that sets out the compensating controls and the acceptance of remaining risk. Unsupported software with no recorded exception is to be marked unauthorised. Check the list for support status no less often than monthly.

What an assessor asks to see: Authorised software list compared with vendor support status, showing only supported software authorised; Exception register for unsupported software with mitigating controls and residual risk acceptance; Monthly support status check record comparing each authorised title with vendor end-of-life announcements; Software register entries for end-of-support titles marked unauthorised where no exception exists; Risk acceptance sign-offs by a named business owner for each unsupported title kept for the mission

Where software lists usually fall short: End-of-life operating systems or Java runtimes still listed as authorised after vendor support ended; Exceptions recorded without compensating controls or an expiry and review date; Support status checked only at annual audit time instead of monthly

Source: CIS Controls v8 (Center for Internet Security), read 30 Sep 2026

NIST SP 800-53 CM-8System Component Inventory

CM-8 System Component Inventory. a. Develop and document an inventory of system components that: 1. Accurately reflects the system; 2. Includes all components within the system; 3. Does not include duplicate accounting of components or components assigned to any other system; 4. Is at the level of granularity deemed necessary for tracking and reporting; and 5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information deemed necessary to achieve effective system component accountability]; and b. Review and update the system component inventory [Assignment: organization-defined frequency].

What an assessor asks to see: Configuration management policy; Procedures addressing system component inventory; Configuration management plan; System security plan; System design documentation; System component inventory; Inventory reviews and update records; Test of Organizational processes for managing the system component inventory; mechanisms supporting and/or implementing system component inventory

Where software lists usually fall short: The component inventory omits components found on the network, or double-counts components assigned to other systems; The inventory lacks the defined accountability information and is not reviewed and updated at the defined frequency

Source: NIST SP 800-53 Rev 5, read 30 Sep 2026

See the specimen list run Check your own list