Safeguard 2.2: Ensure Authorized Software is Currently Supported

Safeguard 2.2 requires you to confirm that every piece of software on your authorized software list is still supported by its publisher (or an approved support provider) and to remediate anything that is end-of-life. Operationalize it by maintaining an authoritative inventory, mapping each title/version to support status, and enforcing a simple rule: unsupported software cannot remain authorized without a time-bound exception and compensating controls. ¹

Key takeaways:

• Your “authorized software” list must include support status, not just names and versions. ²
• End-of-life software needs a defined path: upgrade, replace, isolate, or remove, with tracked closure. ²
• Auditors will ask for proof the process runs on a cadence and that exceptions are governed and time-bound. ²

“Supported software” is a security control, not a procurement preference. If the publisher no longer provides security patches, you lose the normal path to vulnerability remediation and you inherit permanent exposure that defenders can only partially mitigate. Safeguard 2.2: ensure authorized software is currently supported requirement sits inside CIS Controls v8’s software asset management expectations and is usually tested through a single question: can you prove that what you allow to run in your environment is still patchable?

For a Compliance Officer, CCO, or GRC lead, the fastest way to make this real is to convert the requirement into a repeatable operating loop: (1) maintain an authorized software list that is tied to what is actually installed, (2) track vendor support status at the product-and-version level, (3) block or remove end-of-life software, and (4) manage any exceptions with defined compensating controls and an expiration date.

This page gives you requirement-level implementation guidance you can hand to IT, Security Operations, and Asset Management, then audit without guesswork. Primary sources for the requirement are CIS Controls v8 and CIS Controls Navigator v8. ¹

Regulatory text

Excerpt (as provided): “CIS Controls v8 safeguard 2.2 implementation expectation (Ensure Authorized Software is Currently Supported).” ¹

What the operator must do:
You must have a mechanism to ensure software you authorize for use is still within a supported lifecycle so that security updates remain available. Practically, that means your authorized software list cannot be static. It needs support-status fields, a review motion, and enforcement steps when software becomes unsupported (upgrade/replace/remove) or when a business-approved exception is granted with compensating controls and a time limit. ²

Plain-English interpretation

If you allow it, you must be able to patch it. “Authorized” software that is out of support is a governance failure because you cannot rely on the vendor to issue fixes for new vulnerabilities. Safeguard 2.2 expects you to prevent “approved but unpatchable” tools from quietly accumulating across endpoints, servers, and enterprise applications. ²

Who it applies to

Entity types: Enterprises, service organizations, and technology organizations that adopt CIS Controls v8 as a framework expectation. ²

Operational context (where this becomes real):

• Endpoint fleets (managed laptops, VDI, kiosks)
• Server environments (Windows/Linux servers, golden images, containers where applicable)
• Enterprise apps (ERP/CRM clients, browsers, plugins, PDF readers, Java runtimes)
• Third-party-delivered software (commercial off-the-shelf tools and embedded components where you can control versions)
• M&A or inherited environments where “temporary” legacy apps tend to persist

Typical owners: IT Asset Management (inventory), Security (policy and enforcement), Endpoint/Server Engineering (remediation), Application Owners (business justification), Procurement/Vendor Management (support terms for purchased software).

What you actually need to do (step-by-step)

1) Define “authorized software” and the support rule

Create a short standard that answers:

• What counts as “software” in scope (OS, applications, agents, browser extensions, libraries if you track them)
• What “supported” means (publisher support, paid extended support, or a formally approved third-party support arrangement)
• The enforcement rule: “Unsupported software is not authorized” unless an exception is approved, time-bound, and tracked to closure. ²

Operator tip: Write this as a one-page control card with objective, owner, triggers, steps, and exceptions so the control is runnable, not aspirational. ²

2) Build (or fix) the authorized software list so it is auditable

Minimum fields that make audits go smoothly:

• Product name, publisher
• Version(s) authorized (be explicit)
• Platform (Windows/macOS/Linux, server/endpoint)
• Business owner and technical owner
• Approval date, approver
• Support status (supported / approaching end-of-life / end-of-life)
• Support reference (link or document pointer to the vendor lifecycle page or contract terms)
• Next review date
• Standard remediation path (upgrade target version or replacement product)

Store it where it can be governed (GRC tool, CMDB, or a controlled system of record). The key is that the list is authoritative and traceable. ²

3) Reconcile authorized list vs. actual installed software

This is where most programs fail: the authorized list exists, but nobody proves it matches reality.

Operational steps:

1. Pull installed-software inventory from your endpoint management and server management sources.
2. Normalize names/versions (same product shows up with multiple strings).
3. Identify:
   • Installed but not authorized (unauthorized software)
   • Authorized but not installed (low risk, but clean it up)
   • Installed and authorized, but version drift (authorized version differs from installed version)

Document the reconciliation output and create remediation tickets for the deltas. ²

4) Determine support status at the version level

For each authorized title/version:

• Confirm it is still supported by the publisher (or your approved support provider).
• Record end-of-life milestones where available (end of standard support, end of extended support).
• If your organization buys support via a third party, retain the contract/SOW language that indicates what is covered.

Make this a recurring control activity with a defined cadence and triggers (new software request, major version release, vendor lifecycle update, vulnerability alert tied to an old version). ²

5) Enforce: remediate unsupported software with a standard playbook

When something is unsupported:

• Preferred: upgrade to a supported version.
• If upgrade is not possible: replace with an alternative product.
• If replacement is delayed: isolate and harden (network segmentation, restrict privileges, remove internet access where possible, enhanced monitoring), then remove on a defined timeline.
• If the app is business-critical legacy: require an exception with compensating controls and an owner-accepted risk statement.

Track remediation to validated closure. “Validated” means you confirm the unsupported version is no longer present in inventory scans, not just that a ticket was closed. ²

6) Govern exceptions so they do not become permanent

Define exception rules:

• Who can request (app owner) and who approves (security + business risk owner)
• Required compensating controls checklist
• Expiration condition (date-based or event-based, such as “until migration completes”)
• Required re-approval to extend
• Evidence requirements (risk acceptance, mitigation plan, monitoring plan)

Auditors commonly view exception discipline as the difference between “we found some legacy” and “we run uncontrolled legacy.” ²

7) Run control health checks and report

A lightweight monthly or quarterly review should answer:

• What authorized software is approaching end-of-life?
• What is already end-of-life and why is it still present?
• Are exceptions within their expiration window?
• Are remediation tickets closing with validation evidence?

If you use Daydream, this is a natural place to store the control card, attach the minimum evidence bundle each cycle, and track remediation items to validated closure with due dates in a single system of record. ²

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Control design (static artifacts):

• Safeguard 2.2 control card/runbook (objective, owner, cadence, triggers, exception rules) ²
• Authorized software standard/policy section covering “supported software only” ²
• Exception procedure + compensating controls checklist ²

Control operation (per-cycle artifacts):

• Current authorized software list export (with support status fields) ²
• Inventory reports showing installed software population (endpoints/servers) ²
• Reconciliation report (authorized vs installed, version drift) ²
• Evidence of support verification for sampled products (vendor lifecycle page capture, contract excerpt, or support attestation) ²
• Remediation tickets and closure proof (post-change inventory scan, uninstall report, upgrade confirmation) ²
• Exception approvals, risk acceptance, compensating controls evidence, and expiration tracking ²
• Control health check summary and follow-up actions ²

Common exam/audit questions and hangups

Expect these questions in audits, customer diligence, and internal control testing:

1. “Show me your authorized software list. Who approves changes?”
   Hangup: list exists but has no owners, approval history, or version specificity.

2. “How do you verify software is supported?”
   Hangup: teams assert “we patch monthly” but cannot show the vendor still publishes patches for that version.

3. “Prove you detect end-of-life software in production.”
   Hangup: CMDB is incomplete; servers are missing; inventory sources disagree.

4. “How do you handle exceptions?”
   Hangup: exceptions have no expiration; no compensating controls; no evidence of monitoring.

5. “Show remediation from last cycle.”
   Hangup: tickets closed without validation (no scan output, no uninstall logs).

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits	Fix that works
Treating “supported” as a product-level attribute only	A product can be supported while your deployed version is end-of-life	Track support status by version and platform in the authorized list 2
Relying on policy statements without a runbook	Auditors test operation, not intent	Create a control card with owners, cadence, triggers, and steps 2
Inventory without reconciliation	You can’t show unauthorized or drift conditions	Produce a reconciliation output each cycle and ticket the deltas 2
Exceptions that never expire	Legacy becomes the default	Require time-bound exceptions with re-approval and closure tracking 2
Closing remediation tickets without proof	“Done” is not “verified”	Attach post-change inventory evidence to each closure 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, unsupported software increases:

• Vulnerability exposure without vendor patches
• Likelihood of control failures in vulnerability management and secure configuration programs
• Customer trust issues during security reviews when you cannot show lifecycle discipline

For regulated environments, unsupported software also complicates incident response because containment often depends on patch availability and known-good upgrade paths. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize the control)

• Assign an owner and backups; publish a Safeguard 2.2 control card with cadence, triggers, and exception rules. ²
• Identify inventory sources of truth for endpoints and servers; document gaps.
• Create the first authorized software list baseline with minimum fields, including support status placeholders. ²
• Define what evidence you will retain each cycle (inputs, approvals, outputs, retention location). ²

Days 31–60 (prove operation with one full cycle)

• Run your first reconciliation: installed vs authorized, and version drift. ²
• Triage findings into: uninstall, upgrade, replace, or exception required.
• Verify support status for your highest-risk/highest-prevalence software first (browsers, PDF readers, runtimes, remote access tools).
• Start remediation tickets and require validation evidence at closure. ²

Days 61–90 (institutionalize and harden)

• Add automated gates where feasible (software request workflow checks support status; endpoint controls block unapproved installers).
• Establish the recurring control health check and reporting format; track remediation items to validated closure with due dates. ²
• Audit your exception population: expirations, compensating controls, and overdue removals.
• Prepare an “audit-ready evidence bundle” so you can answer common requests in hours, not weeks. ²

Daydream can help by giving you a single place to keep the control card, attach each cycle’s evidence bundle, and manage exception approvals and remediation tracking without losing context across email and ticketing systems. ²

Frequently Asked Questions

Does Safeguard 2.2 require me to remove all end-of-life software immediately?

CIS Safeguard 2.2 expects authorized software to be currently supported. If you cannot remove it quickly, document a time-bound exception with compensating controls and a tracked remediation plan. ²

What counts as “supported” if the vendor offers extended support for a fee?

Paid extended support can meet the intent if it provides ongoing security fixes for the deployed version and you can retain evidence (contract terms or support confirmation). Record the support basis in your authorized software list. ²

How deep do we go on versions: major version, minor version, patch level?

Track at the level your tooling can reliably detect and your risk warrants. For common desktop software, major/minor version is usually necessary to avoid approving a supported product while running an unsupported version. ²

What about software embedded in appliances or delivered by a third party?

If you can control or influence the version, include it in scope and track support status. Where the third party controls patching, treat it as a third-party dependency and retain evidence of support obligations and update practices. ²

How do auditors sample this control?

They typically select a sample from your authorized software list and ask you to prove current support status, then trace to installed inventory and show remediation or exception handling for any unsupported instances. ²

We have multiple inventories (EDR, MDM, CMDB) that disagree. Is that a failure?

Disagreement is common; the control expectation is that you choose authoritative sources, document known gaps, and reconcile routinely with tracked remediation. Keep the reconciliation output as evidence of operation. ²

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8