SA-23 Specialization: NIST SP 800-53 requirements

What SA-23 Specialization requires when you select it under NIST SP 800-53

You are reading this section because someone told you SA-23 applies to your system, or because you are tailoring a baseline and must decide whether to select it. SA-23 Specialization asks the organization to modify, augment or reconfigure defined systems or components that support mission essential services or functions, so that they are more trustworthy than the general-purpose product they started as. No SP 800-53B baseline assigns SA-23, so it enters your program only when you select it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and marks it as an assurance-related control.

The risk it addresses is the gap between what a general-purpose product is built to do and what a mission essential function can tolerate. Off-the-shelf components are designed for a broad market, so their defaults, extensions and trust assumptions may be ones the organization cannot accept for its most critical functions. SA-23 gives the organization a way to respond by changing the component itself, not only by surrounding it with other controls. That is why the control is hard to satisfy in practice. The organization must decide which systems and components count as supporting mission essential functions, what kind of modification is in scope, and how much trustworthiness gain is enough to justify it.

In Release 5.2.0, SA-23 has two organization-defined parameters and no control enhancements, so the parameters carry most of the work. Confirm them against your own selection before you assess anything. Also confirm, with your authorizing official or program office, whether the control is required at all for your system, since FedRAMP's Rev5 baselines do not require SA-23 at Class B, C or D. Before you select SA-23, write down the components in scope, the modifications planned, the owner of each change, and the evidence you will keep, because the assessor will look for documented evidence of design modification, augmentation or reconfiguration.

Which components and decisions bring SA-23 into scope

SA-23 applies only when an organization selects it, so scope starts with a few decisions that connect mission essential functions to the components that support them. Each card below is a decision or check that determines whether SA-23 belongs in the system's control set and how far its work reaches.

Define mission essential functions

Start by naming the functions the system must keep performing under adversity, such as a service whose loss would stop a core business or mission process. SA-23 is tied to these functions, so a vague definition produces an unbounded scope. Write the definition down, get it approved by the business owner, and keep it with the system security plan so an assessor can trace every later decision back to it.

Select the supporting components

Map each mission essential function to the hardware, firmware, software and services that it depends on. Only components that directly support those functions fall under SA-23, so a flat inventory of the whole environment will overstate scope. Record the dependency map and the reason each component was included or excluded.

Decide in-house modification or developer change

Determine whether the organization will modify, augment or reconfigure the component itself, or whether the developer or vendor must make the change. The answer decides who owns the design evidence, who signs the change records and whether acquisition language in SA-4 needs to carry the requirement. Confirm the decision with the team that will hold the evidence.

Tailor SA-23 into the control set

Because SP 800-53B does not assign SA-23 to any baseline, add it through tailoring or an overlay and record the rationale. Set its two organization-defined parameters so they describe the actual functions and components in scope. Check related controls RA-9 and SA-8 so that the design and risk evidence is not duplicated or left out.

Confirm cloud service requirements

FedRAMP's Rev5 baselines do not require SA-23 at Class B, C or D, so a cloud service may not need it unless its authorization or a customer contract says so. Ask the authorizing official or contract owner whether SA-23 is in the agreed control set before building the evidence. Illustrative example: a provider with an agreed Class C baseline may find that SA-23 is outside its required set.

How an assessor tests SA-23 and what they ask to see

This table lists the SP 800-53A test methods for SA-23, the records an assessor asks for, and the findings that most often stall the assessment. Read it as a checklist of what your team should have ready before an assessor arrives, because SA-23 only applies when your organization has selected it through tailoring or an overlay.

Assessment element	What the assessor does or asks for	Common finding
Determination statement	SP 800-53A Release 5.2.0 gives SA-23 one determination statement. The assessor decides whether the organization modified, augmented or reconfigured defined components that support mission essential functions to raise their trustworthiness.	Assessor cannot tell which components are in scope because the mission essential functions were never named
Examine method	Reviews documented evidence of design modification, augmentation or reconfiguration for each defined component, including the design records and the change approvals behind them.	Changes exist only in engineering tickets or memory, with no design record that describes the modification
Interview method	Asks system owners, architects and mission owners how the modifications were chosen, who approved them and how they are kept current after later changes.	Interviewees describe the modification differently, or no one owns the decision after the original build
Test method	Checks that the modified or reconfigured component behaves as the design record describes, for example by comparing the deployed configuration with the documented design.	Deployed configuration has drifted from the documented design, with no record of the drift
Organization-defined parameters	Confirms that the two parameters for SA-23 are defined for the organization and applied to named systems or components.	Parameters are left at placeholder values or defined too broadly to test
Link to mission function	Looks for a traceable line from each modified component to the mission essential function it protects and the trustworthiness problem the change addresses.	Modifications are listed without rationale or without a link to the function they protect
Related controls	Cross-checks the SA-23 evidence against RA-9 (criticality analysis) and SA-8 (security and privacy engineering principles), which often supply the criticality basis and design reasoning.	Criticality analysis is missing or outdated, so the choice of components cannot be justified
Evidence package	Asks for a dated, versioned list of modified components, design records, approvals and test results, kept in the system security and privacy plan or its supporting documents.	Evidence is scattered across repositories and cannot be tied to a specific system release

How to implement SA-23 in six steps

This sequence turns SA-23 Specialization from a selected control into documented, tested and traceable modifications to the components that support mission essential functions. Each step produces an artifact an assessor can examine.

Define mission essential functions and set the parameters
Name the mission essential services or functions the system supports, using the organization's own mission and business impact analysis. Fill in the two organization-defined parameters in SA-23, which set the systems or components in scope and the trustworthiness goal. The output is a short scoping record approved by the system owner and the authorizing official, stating what SA-23 covers and why. The step is complete when every function in the record can be traced to a mission owner.
Identify the supporting components
Map each mission essential function to the hardware, firmware, software, configurations and services that it depends on, using the component inventory and architecture documentation maintained under the system security and privacy plan. Involve platform engineering and the teams that operate the components, because inventories often miss firmware, build tooling and management planes. The output is a dependency register listing each component, its owner and its role in the function. The step is complete when the system owner confirms that no dependency on a mission essential function is missing.
Assess whether existing controls are sufficient
For each component in the register, determine whether current controls, such as hardening, patching, monitoring, access restriction and supplier assurance, can make it trustworthy enough for its role. Record the reasoning component by component. If existing controls cannot close the gap, the component moves to a modification path (this step) or, where modification alone cannot achieve trustworthiness, to SA-20 Customized development of critical components and the engineering principles in SA-8. The output is a sufficiency decision for each component. The step is complete when every component has a recorded decision and the reasoning is signed by the risk owner.
Document the planned change with rationale and owner
For each component that needs modification, augmentation or reconfiguration, write a change description covering what will change, the trustworthiness gap it addresses, the expected effect on the function, the test approach and the accountable owner. Where a change adds a component or replaces one, record that as a design modification for the SA-8 and SA-17 design records. The output is a set of approved change records that an assessor can read without interviewing the team. The step is complete when each record names an owner and a reviewer who is independent of the implementer.
Implement and test under change control
Build the change in a controlled environment and route it through the organization's configuration change process, including approval, peer review and rollback planning. Where the component is code or configuration held in a repository, protected branches and reviewed merge requests can enforce who may push or merge changes, and a static analysis tool such as Semgrep can run in the pipeline with custom rules that reflect the trustworthiness goal. Test the component against the intended behavior and against the mission function it supports. Configuration checks such as Wazuh Security Configuration Assessment or Fleet policies can confirm that the deployed state matches the approved design. The output is test results and deployment records linked to each change record. The step is complete when testing shows the change meets its stated goal and is deployed through the approved path.
Record results and link them to the security plan
Update the component inventory, configuration baselines, the system security and privacy plan and the plan of action and milestones so they reflect the modified components and any open gaps. Record the final determination for each component and the evidence that supports it, including the change record, test results and the sufficiency decision from earlier steps. Ask an independent assessor to examine the evidence against the SA-23 determination statement in SP 800-53A, which uses examine, interview and test methods. The output is an SA-23 evidence package traceable from mission function to component to change to test. The step is complete when the assessor can trace one mission essential function through the full chain without gaps.

Evidence that passes an SA-23 assessment

SA-23 is assessed on documented evidence that the organization chose specific components, changed them on purpose and verified the result. The cards below cover the artifacts that connect those steps, so an assessor can trace a selected component from its mission role to its tested, approved configuration.

Parameter definitions and mission list

SA-23 has two organization-defined parameters, so the first artifact is the written definition of which systems or components the control applies to and which mission essential functions justify them. Record the function, its owner and the reason each component supports it. Review this list whenever the system boundary, the mission or the tailoring decision changes, and date each revision so an assessor can see what was in force during the assessment period.

Component list with justification

List every component selected under SA-23 with its version, owner and the trustworthiness concern it addresses, such as a general-purpose product that cannot meet the mission's integrity or availability needs without changes. A short written justification for each entry shows the selection was a deliberate risk decision rather than a default. Refresh the list at each change window and after any component is retired or replaced.

Design modification and reconfiguration records

Keep a record for each modification, augmentation or reconfiguration that states the original design, the change made, the security property it targets and the design reasoning. Architecture diagrams and design notes should be updated with the change, so the records match what runs in production. These records are the core examine evidence SA-23 assessors look for, and gaps here are hard to fill after the fact.

Test results showing the change works

Attach test results that show each modification performs as intended and does not weaken the function it supports. Include the test plan, the pass and fail record, and any defects found and fixed. Where the change adds monitoring or hardening, test that the control triggers as designed, not only that the system still starts. Retain results with the release that carried the change so they can be matched later.

Configuration baselines for reconfigured components

Establish a documented baseline for each reconfigured component and check running systems against it. Automated configuration assessment can compare endpoints with policy files and report deviations, which helps show the reconfiguration persists over time. Confirm that custom policies reflect your changes, because default benchmark policies will not know about the design choices you made.

Change tickets linking steps to approval

Tie every design change, code change and deployment to a ticket that records the requester, the approver, the test evidence and the release date. Protected branches in a source control platform can enforce that changes reach the main line only through reviewed merges, which gives the ticket and the commit a verifiable link. Confirm with your assessor which change records they will sample and how far back they will look.

Open-source tools that support SA-23 evidence

SA-23 asks an organization to show that it modified, augmented or reconfigured the components behind mission essential functions. The four tools below can produce pieces of that record, from configuration state to code change history, but none of them satisfies the control by itself. Confirm each tool's fit with your environment before relying on its output in an assessment.

Configuration baseline checks with Wazuh

Wazuh's Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies. These policies are mostly based on CIS benchmarks and can be extended with custom policies that check files, directories, registry keys and running processes. For SA-23, a custom policy written from the reconfigured design can show that a component matches its intended settings. Confirm that your endpoint coverage includes every component in scope and that your custom policies trace back to the design documentation.

Ongoing state checks with Fleet

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries. The policies page shows which devices in each fleet pass or fail each policy. This gives a running record that a modified or augmented configuration persists over time, not only at the moment of change. Ask whether your team can export pass and fail history for the audit period, since a single snapshot rarely demonstrates ongoing trustworthiness.

Change control records in GitLab

GitLab Community Edition (MIT) protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These settings support SA-23 evidence where a design modification is implemented as code. The merge history then shows who approved each change. Confirm that protections are applied to every branch that deploys to the in-scope component, not only to the default branch.

Code analysis in CI/CD with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including C/C++, Go, Java, Python, Rust, Terraform and TypeScript, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously. For a modified or augmented component, custom rules can encode the trustworthiness requirements from the design, and scan results give a dated record that the new code was checked. Verify that the languages your component uses are covered by the Community Edition before you commit to it.

What meeting SA-23 costs in money and effort

This table breaks down the cost components of meeting SA-23 Specialization, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to compare quotes, since NIST does not estimate compliance costs and no price or duration is given here.

Cost component	One-time or recurring, and who pays	What drives it up	How to keep it down
Engineering time to define parameters and design the modification	One-time per defined component. Paid by the organization's engineering staff or an implementation partner under a written scope.	Number of mission essential components selected, and how many organization-defined parameters must be set for each	Scope only the components that truly support mission essential services, and reuse one parameter definition across similar systems
Modification, augmentation or reconfiguration work	One-time for each change, with rework whenever the design changes. Paid as build labor by the organization or its partner.	Custom code instead of configuration, and changes that touch many dependent components	Prefer configuration of existing components over custom code where the design allows it, and document each change at the time it is made
Testing and validation of the changed component	One-time per release of the modified component, then repeated after later changes. Paid as test labor and environment time.	Breadth of test coverage needed to show the change increases trustworthiness, and the number of environments to validate	Reuse existing test suites and open-source scanners such as Semgrep Community Edition in CI/CD where they fit
Change control and evidence upkeep	Recurring for as long as the component is in service. Paid by the organization, usually from existing configuration management staff time.	Frequency of changes to the modified component and the number of teams that touch it	Route modifications through the existing change process, and use GitLab protected branches to keep an auditable record of who merged what
Configuration drift monitoring for the modified component	Recurring. Paid for by the organization for tooling and the staff who review results, which may be open-source.	Number of endpoints or hosts running the modified component, and how often its settings are checked	Use open-source tooling such as Wazuh Security Configuration Assessment or Fleet policies with custom checks instead of licensed tools, where they fit the environment
External review or testing of the modification	One-time per modification, sometimes recurring for high-impact systems. Paid to an independent tester or reviewer chosen by the organization.	Criticality of the component, the number of components in scope, and whether the review is a full test or a targeted review	Agree the depth of external testing in writing before work starts, and limit it to the modified components rather than the whole system
Assessor sampling time	Recurring at each assessment cycle. Paid to the independent assessor, who decides the sample and the scope.	Number of modified components, the volume of design and test records the assessor must examine, and interview time	Keep one current design record per modified component so the assessor can sample quickly, and confirm the assessment approach with the assessor early

Who owns SA-23, who can help and what the auditor does

Your organization owns SA-23 in full. The control is implemented by the organization (O) according to Appendix C of SP 800-53 Rev. 5, so no vendor or consultant can accept it on your behalf. Your team must define the two organization-defined parameters in the Release 5.2.0 catalog, identify the mission essential functions and the systems or components that support them, and decide whether a modification is justified at all.

Mission essential function list: Name the services whose disruption would defeat the mission, and map each one to the components that support it.
Parameter decisions: Set the organization-defined values for SA-23 and record why they fit your risk appetite.
Risk decision: Accept, reduce or transfer the residual risk of components that remain in general-purpose form, and document the decision in writing.
Final design approval: Review and sign the design of each modification, including who will maintain it after handover.

Check that the parameters and the mission essential function list are dated, approved by a named owner and linked to SA-23 in your system security plan.

Where SA-23 programs usually fall short and how to close each gap

SA-23 Specialization is a tailored, organization-selected control, so most weaknesses come from how the organization defines and records its decision rather than from the engineering itself. The cards below cover the gaps assessors most often find and a concrete fix for each.

Parameters left undefined or copied

SA-23 has 2 organization-defined parameters, and they set which systems or components are in scope and what trustworthiness goal the modification serves. Programs often leave them blank or paste values from another system's template, so the control has no defined boundary to assess. Fix this by writing the two parameters for each system, naming the specific components, and having the system owner sign off on the wording before any design work begins.

No link to mission essential functions

SA-23 applies to components that support mission essential services or functions, so each modification must trace back to a named function. Without that trace, the reason for the change reads as a general hardening project, and an assessor cannot confirm the control was applied where it matters. Build a short table that maps each modified component to the mission essential function it supports, and review that table with the mission owner, not only the security team.

Modifications documented after the fact

Assessors test SA-23 partly by examining documented evidence of the design change. When the record is written weeks after a modification, it often describes the final state and omits the alternatives considered and the reason for the chosen approach. Record the design decision before implementation, store it with the change ticket, and update it when the design changes. Repository history and approved change requests usually show whether the sequence was followed.

No testing evidence for reconfigured components

A reconfigured component that has not been tested against its intended trustworthiness improvement gives an assessor nothing to examine. Teams often verify that the system still works but do not verify that the modification achieved its stated goal. Define the trustworthiness check in advance, such as a configuration assessment or a targeted test, and retain its output. Tools like Wazuh's Security Configuration Assessment can produce repeatable results against a defined policy, although the organization should confirm which checks fit its component.

Decision not revisited as missions change

A modification justified for one mission may no longer fit when the mission, the threat picture or the component's role changes. Because SA-23 is selected through tailoring rather than a baseline, nothing automatically prompts a fresh review. Schedule a review of each SA-23 decision whenever the system's mission or authorization boundary changes, and record whether the existing modification still meets the defined parameters. Keep the review result in the same record as the original decision.

Confusing SA-23 with SA-20

SA-23 modifies or reconfigures existing components to make them more trustworthy, while SA-20 concerns custom building or re-implementing critical components when no viable control can make an existing one trustworthy enough. Teams sometimes cite SA-23 for a rebuild, or cite SA-20 for a configuration change, which misstates the organization's decision. Write down which of the two the organization is applying and why the other does not fit. Confirm the choice against the control text in the SP 800-53 catalog before it appears in the system security plan.

Questions buyers ask about SA-23 cost, effort and outside help

Is SA-23 required by default under NIST SP 800-53?

No. SP 800-53B does not assign SA-23 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. FedRAMP's Rev5 baselines do not require it at Class B, C or D either. Confirm the selection with your authorizing official or contract owner, since they decide whether a system that supports mission essential functions needs it. Appendix C of SP 800-53 lists SA-23 as implemented by the organization, which means your team owns the design work and the evidence.

How much effort does SA-23 take, and what drives it?

Effort depends mainly on how many systems or components the organization defines as supporting mission essential services or functions, and how far each one must be modified, augmented or reconfigured. Two organization-defined parameters are set in Release 5.2.0, so the scope decisions you make early shape everything after them. Other drivers include how many components are commercial products you cannot change, how much existing design documentation you have, and whether the work touches systems already under continuous monitoring. Ask any partner to size the effort against the defined component list, not against the control in general.

How long does an SA-23 effort take?

No federal timeline is set for SA-23, and NIST does not set implementation timelines for SP 800-53 controls, leaving that to OMB Circular A-130 and to the authorizing process. Your duration will depend on the number of defined components, the design changes they need, and how much testing and review the assessor expects. Confirm the expected schedule with your assessor and authorizing official before you commit to dates, and ask any implementation partner to tie each milestone to a deliverable in the written scope.

What does SA-23 need from our internal team?

The internal team has to own the decisions that SA-23 leaves to the organization. These include which systems or components support mission essential services, what trustworthiness problem each change must solve, and who approves the design modification. Your architects must document the changes, your security team must review them against the system security and privacy plan, and your operations team must run the modified components. Your assessor will examine the documented evidence of design modification, augmentation or reconfiguration, so someone internal must be able to explain each change and its purpose.

Can an organization do SA-23 work without an outside partner?

Yes, if the organization has engineers who can change the design of the defined components and document the result. Many teams do the decision and documentation work in-house and bring in help only for specialized engineering or testing. Outside help is most useful when the components are self-hosted open-source platforms that need hardening, configuration changes or integration, or when the team lacks capacity for parallel work. In either case the organization owns the controls. An implementation partner prepares systems and evidence, and only an independent assessor issues the assessment result.

How does SA-23 differ from SA-8, SA-20 and SA-22?

SA-8 applies security and privacy engineering principles across design and development for systems generally. SA-20 goes further by requiring re-implementation or custom building of critical components when no viable controls can make an existing component trustworthy enough. SA-22 deals with unsupported components: you identify end-of-life hardware, software and firmware, replace it or arrange alternative support, and document the risk decision. SA-23 sits between these. It asks for modification, augmentation or reconfiguration of components that support mission essential functions to raise their trustworthiness, and it is often the first step before a decision to re-implement under SA-20. The related controls for SA-23 in the Release 5.2.0 catalog are RA-9 and SA-8.

What should we ask a partner to put in a written scope for SA-23?

Ask for a written scope that names each system or component in the defined list, the specific design modification, augmentation or reconfiguration planned for each, and the evidence each change will produce. The scope should state who owns each control decision, what the partner prepares, and what your internal team must review and approve. Require deliverables such as updated design documentation, change records, test results and a mapping to the SA-23 assessment objects in SP 800-53A. Confirm what is excluded, how changes are handled if the defined components shift, and the acceptance criteria. DeployOpen works from fixed-scope agreements with scope, deliverables and timelines set in writing before work starts, and it does not issue assessment results.

How DeployOpen scopes and prepares SA-23 evidence

DeployOpen works on SA-23 Specialization as an implementation partner: we help define which mission essential components would be modified, augmented or reconfigured, then prepare the design changes and documentation that show the change was made for trustworthiness. The organization owns the decision and the control, and an independent assessor tests it.

How we scope

Agree in writing which defined systems or components support mission essential services or functions for this engagement.
Record the organization-defined parameters for SA-23 so the boundary of the specialization work is explicit.
Confirm with your assessor whether SA-23 is selected through tailoring or an overlay, since no SP 800-53B baseline includes it.

How we build

Design the modification, augmentation or reconfiguration against documented trustworthiness goals for each in-scope component.
Configure supporting checks such as Wazuh configuration assessment, Fleet policies, GitLab protected branches and Semgrep scanning where they fit the component.
Test changed components in a non-production environment before any change is approved for production use.

How we hand over

Deliver design records showing what was changed, why, and which risks each change addresses, mapped to the SA-23 examine objects.
Provide configuration exports, scan results and policy status records that your assessor can examine for the determination statement.
Document the system and its operating procedures so your team can maintain the specialized components after handover.

How we support

Offer ongoing support, upgrades and continuous testing for the specialized components as a retainer, if your organization wants it.
Review the evidence set again whenever a defined component changes, so records stay current for the next assessment.
Confirm with your assessor, before work starts, the evidence format and depth they will accept for SA-23 in your environment.