SA-22(1): Alternative Sources for Continued Support

The sa-22(1): alternative sources for continued support requirement is a software and services continuity control that sits at the intersection of supplier management, asset lifecycle, and contingency planning. It focuses on a simple question assessors ask during incidents and renewals: If the original supplier disappears tomorrow, can you keep the system securely supported? For compliance teams, SA-22(1) is easiest to pass when you treat it as an engineering and procurement obligation with governance wrappers, not a policy-only exercise.

This requirement matters most for components that create “single points of support failure,” such as proprietary appliances, niche SaaS providers, custom-built modules maintained by one contractor, and tools with restrictive licensing or no source access. If your organization supports federal information systems or contractor systems handling federal data, you should expect assessors to look for clear ownership, a current inventory of covered components, and evidence that your alternatives are real (for example, executed agreements, escrow arrangements, or validated internal support procedures), not just ideas captured in a spreadsheet.

Below is requirement-level guidance you can implement quickly: who owns it, what to build, what evidence to keep, where audits get stuck, and how to execute without boiling the ocean.

Regulatory text

Control excerpt: “NIST SP 800-53 control SA-22.1.” ¹

What the operator must do (in practice): SA-22(1) is an enhancement to SA-22 (Unsupported System Components). Your operational obligation is to pre-identify and maintain alternative sources of continued support for system components so the organization can continue to patch, maintain, and securely operate those components if the original supplier cannot or will not provide support. The “alternative source” can be another qualified third party, internal support capability, or a transition plan that removes the dependency within an acceptable timeframe. Your program must be demonstrable during an assessment, not just described. ²

Plain-English interpretation

You need a plan for the “what if” scenario: if the original maker/maintainer is unavailable, you can still do security-relevant maintenance (patching, configuration support, vulnerability remediation, break-fix) without leaving unsupported components running in production.

Think of SA-22(1) as support continuity for the supply chain:

• The component remains in service, so support must remain available.
• If support cannot remain available, you must have a controlled exit (replacement, isolation, decommission) that your risk owner accepts.

Who it applies to

Entities

• Federal information systems and programs assessed against NIST SP 800-53 Rev. 5. ²
• Contractors handling federal data where NIST SP 800-53 controls are flowed down by contract or used for authorization and assessment. ²

Operational context (where SA-22(1) shows up in real life)

• End-of-life / end-of-support notices for operating systems, databases, network devices, security tools, and industrial/embedded components.
• Third-party concentration risk where only one provider can patch or troubleshoot a component.
• M&A, bankruptcy, sanctions, export restrictions, or contract disputes that suddenly remove access to updates or support portals.
• Proprietary or closed-source dependencies where you cannot independently remediate vulnerabilities.

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

1) Define scope: what components must have alternative support

Create a scoping rule that is simple enough to run repeatedly:

• In scope: components that are mission-critical, internet-exposed, privileged-plane, regulatory-bound, or hard to replace.
• Out of scope (usually): low-impact utilities, short-lived dev/test components with automated rebuild, or components already covered by a broader platform support contract that includes substitution rights.

Operator tip: If you can’t explain your scope rule in a few sentences to an assessor, it will sprawl. Tie it to your system categorization and impact analysis approach used for NIST assessments. ²

2) Build a “continued support register” mapped to your inventory

For each in-scope component, capture:

• Component name/version, owner, environment(s)
• Supplier and support channel (OEM, reseller, managed service provider)
• Support end date and renewal/termination triggers
• Security support dependencies (patch feed, signing certs, license server, support portal access)
• Current support status (supported / extended support / custom support / unsupported with exception)

This becomes your control operating record: you update it whenever procurement renews, engineering upgrades, or the supplier announces lifecycle changes.

3) Identify alternative sources that are viable, not theoretical

For each component, document at least one alternative path:

• Alternative support provider: another qualified third party able to provide maintenance and security patches (where legally and technically possible).
• Internal support capability: documented procedures, trained staff, tooling, and access required to operate securely without vendor support.
• Transition option: replacement product/service and a migration plan triggered by support loss.
• Escrow/transfer mechanisms: for software where source access or build artifacts can be released under defined conditions.

Decision check: If the alternative requires negotiations, new hiring, or untested access rights, treat it as “planned” until it becomes contractually and operationally ready.

4) Close the procurement and contract gaps

This is where SA-22(1) either passes cleanly or collapses:

• Add contract language supporting continuity: continued access to updates during disputes, reasonable transition assistance, and clear data/configuration export rights.
• For proprietary software, evaluate whether escrow is appropriate and confirm release conditions match your risk scenario.
• Confirm sublicensing and third-party support rights. Many licenses restrict who can provide support.

Work with legal/procurement to ensure the “alternative source” is permitted under the agreement, not just technically possible.

5) Define triggers and required actions (runbooks)

Write a short runbook per critical component class:

• Trigger events: end-of-support announcement, support portal access revoked, supplier breach, non-renewal decision, material SLA failure.
• Required actions: risk acceptance workflow, compensating controls, accelerated migration, isolation, or decommission.
• Authority: who can approve continued operation in a degraded support posture (system owner, authorizing official, risk committee).

6) Prove it works: test the plan

Assessors respond well to evidence that you rehearsed:

• Tabletop exercises for “support loss” scenarios.
• A controlled test of restoration/migration where feasible.
• Verification that you can obtain patches/updates through the alternate method or execute the transition steps.

Testing can be lightweight, but it must be specific and documented.

7) Operationalize ongoing governance

Set a cadence aligned to your lifecycle management:

• Review the continued support register during renewal cycles and major upgrades.
• Monitor supplier lifecycle advisories.
• Require SA-22(1) review as a gate for onboarding new critical third parties or components.

If you use Daydream for third-party risk and evidence tracking, map SA-22(1) to a named control owner, attach the continued support register, and schedule recurring evidence tasks so audits don’t turn into archaeology.

Required evidence and artifacts to retain

Keep artifacts that prove both design (you planned) and operation (you executed):

• Continued Support Register (current, versioned)
• Component lifecycle/EOL notices and your internal tickets responding to them
• Contracts/SOWs showing support terms, transition assistance, escrow clauses, or substitution rights
• Support arrangements with alternates (MSA, quotes, executed agreements, or approved onboarding records)
• Runbooks for support-loss triggers and response steps
• Risk acceptances and exception approvals where components operate in reduced support conditions
• Test results: tabletop notes, exercise reports, migration drill outcomes, remediation follow-ups
• Training records for internal support capability where “self-support” is the alternative

Common exam/audit questions and hangups

Assessors tend to ask variations of:

• “Show me which components would be impacted if Vendor X stopped support tomorrow.”
• “Where is the documented alternative support source for this specific component?”
• “Is the alternative permitted by license and contract?”
• “How do you know the alternative works? Show a test or an executed transition plan.”
• “Who approved continued operation when support lapsed?”

Hangups that slow audits:

• Inventory can’t be reconciled to reality (assets not tagged to systems/owners).
• Alternatives exist but are not documented per component.
• Procurement terms contradict the claimed alternative (for example, no third-party support allowed).
• Exceptions exist without time bounds or without compensating controls.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-22(1) as a generic policy statement.
   Fix: Tie evidence to specific components and specific alternates.

2. Mistake: “Alternative source” equals “we’ll find someone.”
   Fix: Require either an executed agreement, a vetted internal capability, or an approved transition plan with identified target state.

3. Mistake: Ignoring SaaS and managed services.
   Fix: For SaaS, alternatives often look like data export + migration path + contractual transition assistance. Document that explicitly.

4. Mistake: Exceptions that never expire.
   Fix: Put clear exit criteria on unsupported components and track them like remediation items.

5. Mistake: No linkage to contingency planning.
   Fix: Cross-reference your contingency plan and incident response triggers so “support loss” is treated as an operational event, not only a procurement problem.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SA-22(1) primarily as an assessment and authorization risk under NIST-based programs. The practical risk is straightforward: unsupported components accumulate unpatched vulnerabilities, incident recovery slows, and you can lose the ability to meet security baselines because you cannot obtain fixes. ²

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Assign a control owner (usually: CISO org + IT asset lifecycle owner + procurement delegate).
• Define “in-scope component” criteria and publish it as an internal standard.
• Build the continued support register template and populate it for your highest-impact systems first.
• Identify obvious single points of support failure and log them as tracked risks.

Days 31–60 (make alternatives real)

• For each in-scope component, document at least one alternative path and classify it as “ready” or “planned.”
• Start contract reviews for critical third parties: confirm portability, transition assistance, and support rights.
• Draft runbooks for top risk scenarios (support portal access loss, EOL notice, termination).
• Establish an exception workflow for components that cannot meet SA-22(1) yet.

Days 61–90 (prove operation and readiness)

• Run tabletop exercises for at least one “support loss” scenario per major system boundary (core infrastructure, key business application, security stack).
• Convert “planned” alternatives to “ready” where feasible (execute agreements, onboard alternates, train staff).
• Package evidence for assessment: register, contracts, runbooks, tests, and exceptions.
• Set recurring review tasks in your GRC system; Daydream works well when you attach artifacts to the control and schedule evidence refreshes tied to renewals and lifecycle milestones.

Frequently Asked Questions

Does SA-22(1) require a second vendor for every product?

No. It requires a viable alternative source of continued support, which can be another third party, internal capability, or a documented transition plan that removes the dependency. The key is that the alternative is actionable and permitted under your agreements. ²

What counts as “continued support” for SaaS where we don’t patch anything?

For SaaS, “continued support” typically means your ability to maintain secure operations through contractual support, incident response coordination, and an exit path (data export, configuration export, and transition assistance). Document the alternate approach as migration readiness rather than patch access.

How do we handle proprietary software where third-party support is contractually prohibited?

Treat that as a constraint and choose another alternative: escrow (if available), negotiated transition assistance, or a pre-approved replacement plan. Retain the licensing language as evidence and show your approved compensating plan.

What evidence do auditors actually want to see?

They want traceability from a critical component to an identified alternative and proof that it’s feasible. The most persuasive evidence is an up-to-date register, executed contracts/terms, and a test record or exercise notes tied to a real scenario.

Can internal support be the alternative source?

Yes, if you can show internal capability is real: trained staff, documented procedures, necessary access to builds/configurations, and a way to remediate vulnerabilities without the original supplier. Keep training and runbook evidence.

How should we track SA-22(1) across many systems without drowning in spreadsheets?

Treat it as a control with a single enterprise register fed by your CMDB/asset inventory and procurement system, then map exceptions and evidence per system. A GRC workflow (including Daydream) helps by assigning ownership, collecting artifacts, and prompting refreshes on a schedule.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5