What SC-25 thin nodes asks for, and why it is a tailoring decision
SC-25 requires an organization to limit the functionality and information storage on defined system components so that those components offer an attacker less to exploit. No SP 800-53B baseline (low, moderate, high or privacy) includes it, so it applies only when the organization selects it through tailoring or an overlay. Start by finding out why the reader is seeing it: an assessor may have raised it against a system that already has thin clients in scope, or a contract may list it explicitly. Either way, the first question is whether the system actually has components that fit the definition, because a control that is not selected is not assessed, while a selected control with no defined components is an immediate finding.
The attack surface reasoning is simple. A thin client or similar node that runs only a browser session, a remote display protocol and a small management agent has fewer installed packages, fewer services, fewer local accounts and less cached data for an attacker to reach. Local storage matters as much as functionality, since residual files, tokens and credentials on a device that is lost or stolen can outlive the session that created them. SC-25 has one organization-defined parameter, which means the organization must name the component types it covers and state what minimal means for each. That definition is where most of the effort goes. Ask the system owner to list each component type, the functions it must keep, the storage it may hold, and the configuration baseline that proves those limits.
Proving the minimal configuration is harder than writing it down. An assessor will examine system design documentation, configuration settings and audit records, and will interview the people who manage the nodes (SP 800-53A lists two determination statements for the control). Confirm with your assessor which evidence they will accept before you build the baseline. Open-source tools can help here: Wazuh's Security Configuration Assessment checks endpoints against YAML policies and can flag unneeded services or local files, and Fleet policies answer yes or no questions about devices through osquery, showing which devices pass or fail each check. Treat these as evidence sources to confirm against your own minimal baseline, not as proof that SC-25 is met.
Which components fall under SC-25 when you select it
SC-25 applies only when your organization selects it through tailoring or an overlay, so the first job is deciding which components count as thin nodes. The cards below cover the component types, the storage decision, image ownership and the organization-defined parameter, which together determine how much work the control creates.
Defining the component types
Start by listing every device class that could be treated as a thin node: thin clients, kiosks, virtual desktop endpoints and appliances. SC-25 asks you to define which system components it covers, so an unlisted device type is effectively outside the control's scope. Ask whether shared workstations, point-of-sale terminals or lab instruments belong on the list, and record the reasoning in the system security plan so an assessor can trace each inclusion or exclusion.
Deciding whether local storage is permitted
Decide, per component type, whether any local storage is allowed at all. A device that boots from read-only media and keeps only session state in memory has a very different evidence trail from one that caches credentials or documents on disk. Document the answer as a configuration requirement, then confirm with the device vendor which storage features can be disabled and how that is verified.
Assigning image ownership
Thin nodes usually run a single managed image pushed from a central location, so the team that builds and signs that image effectively sets the control's limits. Name an owner for each image, define who may request changes, and require that changes pass through your configuration management process. Without a named owner, assessors tend to find drift between the documented minimum functionality and what devices actually run.
Setting the organization-defined parameter
SC-25 has one organization-defined parameter in Release 5.2.0, which you must fill in to make the requirement testable. Write down the functions each component type must provide, the storage it may hold and the services it may run. Vague wording such as minimal use will not give an assessor anything to test, so state the limits in terms a configuration scan can check.
Confirming the control is selected
SC-25 is not part of any SP 800-53B baseline, so it appears in your control set only when you select it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system (S). Record the selection and its rationale in your tailoring documentation, and confirm with the authorizing official or your compliance lead whether any overlay you follow already requires it.
Mapping related SC controls
SC-25 sits alongside SC-30 and SC-44 in the Release 5.2.0 catalog, so the same devices may also fall under other SC controls. Review how your thin node design interacts with the device and port controls you select, such as SC-41, and with any boundary protection you apply to the networks these devices reach. Overlapping scope is easier to explain in one place than to reconstruct during assessment.
How an assessor tests SC-25 under SP 800-53A
The first examine method reviews system design documentation. The assessor needs a written definition of which components are thin nodes, what functions they perform and what information they may hold locally. Without that definition, there is nothing to test against, so the assessor will trace the component set from the system security plan into the design material and check that the two agree.
- Component definition: named device classes, such as thin clients or kiosks, with the reason each one is in scope.
- Functional scope: the functions each component may perform and the functions it must not perform.
- Local storage rules: what, if anything, may be stored on the device and what must come from central services.
- Traceability: the same component set appears in the security plan, architecture diagrams and asset inventory.
- Parameter value: the organization-defined parameter for SC-25 is filled in with a concrete value.
Check that the design document names the components and their limits in terms an engineer could build against, and that no component can join the set without a documented decision.
The examine method also covers system configuration settings with their associated documentation, and system audit records. The assessor compares documented limits with the settings that actually apply: installed software, enabled services, local storage paths and peripheral policies. Audit records then show whether those settings change only through approved activity.
- Baseline images: the image or build template for each component, with its version and build record.
- Enabled software and services: installed packages and running services compared with the approved list.
- Storage configuration: local disk, cache and persistence settings, including whether user data is written to the device.
- Change records: audit entries that show who changed an image or setting, and when.
- Configuration procedures: the documented method for applying settings and detecting drift.
Check that each documented limit maps to a setting you can point to, and that the audit trail covers every change to those settings.
The interview method puts questions to the administrators, platform engineers and service desk staff who build, deploy and support the components. The assessor is testing whether the people who run the components give the same account as the design documents, and whether they can show the evidence behind their answers. Answers that differ between interviewees are a finding in themselves.
- Scope question: "Which devices are thin nodes, and who decides when a new device type joins that set?"
- Storage question: "What can a user save or cache on these devices, and how is that enforced?"
- Drift question: "How do you detect a device that has gained software, services or local storage outside the approved build?"
- Lifecycle question: "What happens to data on a device that is lost, reimaged or returned?"
- Exception question: "Who approves exceptions to these limits, and how long do they stay open?"
Check that answers from different administrators match the design document and that each person can name the artifact that supports what they said.
The test method checks behavior on real devices instead of documents. The assessor selects a sample of components and verifies that the limits hold in practice, for example by attempting to save files to locations the design prohibits or by comparing running processes with the approved list. Policy-based scanners can support this work. The Wazuh Security Configuration Assessment module checks files, directories, registry keys and running processes against YAML policies, and Fleet policies answer yes or no osquery questions for each device. Scanner output counts as test evidence only when the assessor can confirm what the policy checks.
- Sample selection: a documented method for choosing devices across sites, images and user groups.
- Storage test: an attempt to save data to a prohibited location, with the result recorded.
- Software and process check: installed software and running processes compared with the approved list.
- Policy evidence: the policy content, its version and the pass or fail results for each sampled device.
- Reimage test: confirmation that a reimaged device returns to the approved state.
Check that the sample method is written down, that the test steps can be repeated and that each result names the device, the policy version and the date.
The assessor decides findings, not the organization or its implementation partner. SC-25 is not in any SP 800-53B baseline, so these findings arise only where an organization has selected the control. The most common gaps come from the design stage, where the component set or its limits were never written down clearly enough to test.
- Undefined component set: no list of which devices are thin nodes, so no test can be scoped.
- Unverified local storage: settings say local storage is off, but no test confirms it on a device.
- Documentation without configuration evidence: the design describes one state and the image shows another.
- Unlogged changes: configuration changes with no audit record of who made them.
- Open exceptions: approved deviations with no owner or review date.
Before an assessment, test each item above in your own environment and confirm with your assessor which evidence they will accept.
Implementing SC-25 in a self-hosted environment
This sequence turns SC-25 from a policy statement into a set of defined component classes, documented minimal profiles, hardened images and verified devices, with exceptions and reviews recorded so an assessor can trace each thin node back to an approved decision. Because SC-25 is not in any SP 800-53B baseline, the sequence starts with confirming that the control was selected for the system.
Confirm the control is selected and scoped
Start by confirming that SC-25 appears in the system's control selection, either through tailoring or an overlay, since SP 800-53B does not assign it to any baseline. The organization owns this decision, and the system security and privacy plan should record the selection and the reason for it. Ask the implementation partner to map which device types in scope could act as thin nodes, such as thin clients, kiosks or virtual desktop endpoints. The output is a short scoping record that names the SC-25 selection, its owner and the system boundary it covers.
Define component classes and the parameter
SC-25 carries one organization-defined parameter in Release 5.2.0, so the organization must set the value that determines what counts as minimal. Group the in-scope devices into component classes, for example by operating system image, hardware family or role. For each class, record the parameter value and the reason it is sufficient for the business function. The output is a component class register that an assessor can read against the control text in the SP 800-53 catalog.
Document allowed functionality and local storage
For each class, write down the functions the device must perform and the local storage it may hold, such as cached credentials, temporary files or logs. Everything outside that list is removed or disabled. Security and operations staff should approve the profile, and the document should state which local services, drivers, browsers and removable media paths are allowed. The output is a signed minimal functionality profile per class that can be compared directly with the configuration evidence collected later.
Build and harden the image or profile
Build a golden image or configuration profile for each class from the approved profile, removing unneeded packages, services, local user features and storage locations. Apply the organization's secure configuration baseline and record the build inputs, versions and hashes so the image can be rebuilt. Where a class uses a vendor-supplied image, confirm with the vendor which components can be removed without breaking supported operation. The output is a versioned image or profile with a build record that ties each setting back to a line in the minimal functionality profile.
Verify configuration on sample devices
Deploy the image to a sample of devices from each class and check the live configuration against the profile. Open-source tools can automate this. Wazuh Security Configuration Assessment uses YAML policies, mostly based on CIS benchmarks and extendable with custom checks, to examine files, directories, registry keys and running processes on monitored endpoints. Fleet policies, written as osquery queries, can answer yes or no questions about devices and show which devices pass or fail each policy. Confirm with the tool owner which checks your version supports. The output is a dated scan or query report per class showing passing and failing devices.
Remediate deviations and record exceptions
Investigate every failing check and either correct the device or the profile, depending on whether the deviation is a drift or a flaw in the design. Where a required function cannot be removed, record an exception with the business reason, the compensating measures, the approver and an expiry condition. Keep the exception register separate from the profile so changes stay traceable. The output is a remediation log and an exception register that link each deviation to a closed fix or an approved exception.
Set the review cycle and retain evidence
Set a review cycle for the profiles, exception register and scan results, and assign an owner for each. Re-run verification after every image change, significant configuration change or change in the SC-25 parameter. Retain the signed profiles, build records, scan reports and exception approvals in the evidence store that the assessor will sample from. The review cycle itself is an organizational decision that should be documented in the SC-1 policy. The output is a documented review calendar and an evidence index that an independent assessor can sample against SC-25's two determination statements.
Evidence that passes SC-25 and how to keep it current
An assessor testing SC-25 looks for a short, consistent set of artifacts that together show which thin node profile was chosen, how it is configured, and that the configuration is still true. The cards below cover each artifact and the routine that keeps it accurate between assessments, since a thin node drifts quickly once images and settings change.
Component profile in system design documentation
The design documentation should name each thin node type, its permitted functions, and the functions deliberately removed, such as local applications, local file storage or local administrative shells. Record the organization-defined parameter value that sets the minimal functionality and information storage for each component class. Assessors use this document to decide what they should expect to find in configuration checks, so a profile that names only a device model and not its functions gives them nothing to test against.
Configuration baseline and settings
Capture the approved baseline image and its settings as a versioned document, including disabled local storage paths, removed packages and restricted services. Keep the baseline separate from the fleet inventory so that an assessor can compare the two. Mark which settings enforce the parameter value and which only support it, so the reviewer sees the link between requirement and configuration.
Compliance check results from endpoint tooling
Audit records showing configuration checks are the strongest evidence that the profile is enforced across the fleet, not only on the reference device. Wazuh's Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies, and can be extended with custom policies that reflect your thin node profile. Fleet policies answer yes or no questions as osquery queries and show which devices pass or fail, which gives a per-device record. Confirm with each vendor how long results are retained in your deployment.
Image change log and approvals
Every change to a thin node image, including added drivers, updated browsers or new local components, should be recorded with the date, the reason, the approver and the effect on the profile. Store the image hash or version with each change record so a reviewer can tie a deployed device to the exact image. Without this log, an assessor cannot tell whether an unexpected local capability was approved or added silently.
Re-check after every update
Vendor updates and firmware patches can restore services or storage paths that the profile removed. Make re-running the configuration checks a required step in the update procedure, and record the result before the update is released to the fleet. Pair this with the change log so that each update has a before and after check. Treat a failed check as a change request, not a routine exception.
Periodic review and parameter sign-off
Set a review cycle for the profile and the organization-defined parameter, and record who signed off on the value and any exceptions. The cycle should be set by the organization's own policy for the SC family rather than by a fixed external timeline. Ask the independent assessor which review evidence they expect to see between assessments, since expectations about cadence and sign-off formats vary by organization and authorization program.
What meeting SC-25 costs in money and effort
This table breaks down the cost components of meeting SC-25 Thin nodes, who is paid for each, and whether it is one-time or recurring. No figures are supplied for this control, and NIST does not estimate compliance costs, so use the drivers and quote questions to compare offers.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Defining the thin node standard | Internal architects, with optional outside engineering time | One-time, revisited on change | Number of device types in scope and how many roles each device serves |
| Building minimal images and locked-down configurations | Platform engineering or an implementation partner under a fixed-scope agreement | One-time per image, then recurring with each rebuild | Reuse of a single hardened base image versus separate builds per device model |
| Configuration verification tooling | Open-source tools such as Wazuh or Fleet, run by the organization's own staff | License spend removed for open-source tooling; setup is one-time, operation is recurring | Whether existing monitoring already covers endpoints, and how many policies must be written as custom checks |
| Evidence upkeep | Internal compliance and operations staff | Recurring, tied to review cycles and each change | Frequency of image updates, and whether evidence is generated automatically or collected by hand |
| External review or testing | Independent security testers or an assessor, paid by the engagement | Usually one-time per assessment cycle, plus retesting after major change | Scope of thin node types tested, and whether testing covers local storage limits as well as functionality |
| Auditor or assessor sampling | The independent assessor, who bills the organization | Recurring at each assessment | Number of thin node populations, and how cleanly the organization can show their configurations |
| Software licenses | Vendors of commercial endpoint or configuration tools, if used | Recurring | Choice of self-hosted open-source tools instead of commercial licensing removes this line |
Who owns SC-25 and what an implementation partner can take
The organization owns SC-25 in full. SC-25 requires minimal functionality and information storage on the system components the organization defines, and only the organization can decide which components count as thin nodes, what they may run, and what local storage they may keep. Those decisions depend on the mission, the data the endpoints touch and the risk the organization is willing to accept. Under SP 800-53 the organization also owns the risk acceptance record for any deviation.
- Defined parameter: SC-25 carries one organization-defined parameter in Release 5.2.0. Your security and architecture leads must set it and record the reasoning, because an assessor will read the value you chose against your system design.
- Component selection: Name the device classes that are thin nodes, such as thin clients or kiosks, and state which ones are out of scope.
- Tailoring decision: SC-25 is not in any SP 800-53B baseline, so you must select it through tailoring or an overlay and document why.
- Risk acceptance: Any residual exposure, such as local caching you could not remove, needs a named owner who signs the acceptance.
- Operation: Someone in your organization must review the evidence on a schedule and act on failing devices.
Before engaging anyone, confirm internally who holds each of these decisions, because a partner cannot make them on your behalf.
DeployOpen works as an implementation partner. Within a written, fixed scope, we can prepare hardened configuration profiles, draft policy and procedure content for your review, and build the technical evidence an assessor will examine, all inside your own cloud accounts, data centers or air-gapped networks. We do not decide the defined parameter, accept risk, or issue any audit report, attestation or certificate. Those belong to you and to the independent assessor.
- Hardened profiles: Configuration baselines that limit installed software, services and local storage on the thin node images you approve.
- Policy content: Draft SC-25 policy and procedure text that you review, amend and adopt as your own.
- Evidence pipelines: Scheduled checks with Wazuh Security Configuration Assessment or Fleet policies, so that configuration results and failing devices are recorded for the assessor.
- Documentation: Build and configuration records that tie each setting back to the SC-25 determination statements.
- Handover: Runbooks and a clear record of what was delivered, so your team can operate the profiles without us.
Ask any partner to state in writing which items it will deliver and which decisions remain with you.
The independent assessor tests SC-25 and reaches a conclusion about it. SP 800-53A gives the assessment procedure for SC-25: two determination statements, assessed through examine, interview and test methods. The examine objects include system design documentation, system configuration settings with their documentation, and system audit records. The assessor selects samples, observes results and forms a judgment. The organization and the partner should expect that judgment to be independent of the people who built the controls.
- Independence: The assessor must not design, configure or sign off the controls it tests, which is why a partner's own review cannot replace it.
- Examine and test: Expect requests for design documents, sampled device configurations and audit records showing devices in and out of compliance.
- Interviews: Your administrators and device owners will be asked how thin nodes are managed and what happens when one fails a check.
- Findings and report: Only the assessor issues the findings, assessment report or any certification language.
- Rework: Findings return to the organization as remediation items, which the partner may help fix under a separate, written scope.
Before hiring an assessor, confirm its qualifications and how it handles independence, and ask how it wants evidence delivered.
Where organizations fall short on SC-25
SC-25 is a short control, which is why its gaps tend to be decisions nobody recorded rather than missing tools. The cards below cover the places where assessors usually find nothing to test: an unset parameter, an inherited image, unrecorded local storage, and configuration that was never rechecked after updates.
Organization-defined parameter left unset
SC-25 has one organization-defined parameter, which is where the organization states what minimal functionality and information storage means for each defined component. When that value is blank, the control has no measurable standard, so an assessor cannot tell whether a thin client complies. Action: write the parameter as a specific list of permitted services, applications and storage paths for each component class, and have the system owner approve it.
Vendor default image accepted as-is
Thin client vendors and platform teams often deploy a default image that includes browsers, agents, shells and utilities the business never asked for. Accepting that image without documenting what it contains means the defined functionality was never decided, only inherited. Action: compare the default image against the approved functional list, remove or disable what is not justified, and keep the comparison as a dated record.
Local storage without a recorded decision
Local disks, caches and persistent user profiles on thin nodes can hold credentials, session data or documents that the design never intended to keep locally. Without a recorded decision on what may be stored, nobody can say whether a lost or stolen device exposed sensitive information. Action: state which data classes may reside locally, disable local persistence where it is not needed, and document the exceptions with an owner and a review date.
No check after updates
Updates, firmware changes and reimaging can restore services or storage paths that were removed earlier, so a compliant node can drift without anyone noticing. An assessor testing SC-25 will ask how the organization knows the configuration still matches the defined minimum. Action: run a scheduled configuration check against the approved functional list after each image or firmware change, and keep the results as audit-ready evidence.
Scope drift across device fleets
Thin nodes often sit alongside other endpoints, and the list of components covered by SC-25 is rarely kept in step with the asset inventory. Devices added through procurement or replacement may never receive the thin node settings at all. Action: tie the defined component list to the asset inventory, and ask for a device-by-device pass or fail view so that gaps are visible before an assessment.
Questions about SC-25 cost, effort and scope
Is SC-25 thin nodes required if my system has no SP 800-53B baseline?
No baseline requires SC-25, so it applies only when your organization selects it through tailoring or an overlay, or when a contract, regulator or assessor asks for it. SP 800-53B does not assign SC-25 to the low, moderate, high or privacy baseline, and FedRAMP's Rev5 baselines do not require it at Class B, C or D. Start by checking the authorizing document or contract for a named control list. If SC-25 is not named, your team can still choose it as a risk-based measure for endpoints such as thin clients, and should record that decision and its rationale in the system security and privacy plan.
How much effort does implementing SC-25 usually take?
The effort depends on how many endpoint types are in scope and how much local functionality and storage they currently have. SC-25 has one organization-defined parameter and no enhancements, so the policy decision is narrow, but the technical work can spread across device images, operating system settings and application installs. Ask your implementation partner for a written breakdown by device class. Expect the work to split into defining the minimal function set, configuring each image, and producing evidence that the settings hold over time. No effort figure is supplied here, so ask for one in the written scope rather than relying on a general estimate.
What does my team have to provide for an SC-25 engagement?
Your team owns the control decision and the sign-off. It must define which components are thin nodes, state the minimal functionality and local storage each may keep, and approve the configuration. Your engineers will need access to device images, management consoles, network documentation and the current asset inventory. A DeployOpen engagement prepares systems and evidence against the scope agreed in writing, but it does not decide the organization's risk acceptance or issue any assessment report. Confirm these responsibilities in the statement of work before work starts.
Can we implement SC-25 in-house without an outside partner?
Yes, if your team has the skills to harden endpoint images, manage configuration settings and collect evidence. Teams that already run configuration management for thin clients usually have most of the building blocks. Outside help tends to pay off when the endpoint estate is large, when images are inconsistent across sites, or when the assessor expects specific evidence formats. Whatever route you take, the organization keeps ownership of the control, and only an independent auditor or assessor can issue an assessment result.
What drives the cost of SC-25 up or down?
The main drivers are the number of thin node types, how many devices and sites run them, how many images must be rebuilt, and how much local software or storage has to be removed or locked down. Cost is also shaped by how well the existing endpoint management tools can enforce settings and report on them. Recurring costs include keeping images current, rechecking settings after updates and retaining evidence for the assessment cycle. Ask any provider for a quote that separates one-time setup from recurring work, and that names the device classes, sites and reporting outputs in scope.
How long does it take to implement SC-25?
Duration depends on the number of device classes, the state of current images and how quickly your change approval process moves. No timeline is supplied for this control, so ask any provider for a written schedule tied to the agreed scope, with milestones for definition, configuration, testing and evidence collection. Plan for an assessor to need time to examine system design documentation, configuration settings and audit records, so leave room for that review before your authorization or audit date.
Which open-source tools can show that thin nodes stay locked down?
Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies that check files, directories, registry keys and running processes. Fleet's policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices pass or fail each one. Used together, they can show whether unnecessary functions and local storage are absent over time. Confirm with each vendor that the specific checks you need are supported in your deployment before relying on them as evidence.
How DeployOpen scopes and prepares SC-25 evidence
DeployOpen approaches SC-25 Thin nodes as a scoping and evidence question first: which components in your environment are thin, what they are allowed to do, and what an assessor will need to see. We plan, implement, document and hand over the configuration and evidence in your own infrastructure, while your organization keeps ownership of the control decision and the assessment outcome.
How we scope
- Written scope lists the thin client and similar endpoint types that SC-25 covers in your environment.
- Scope records which functions and local storage are removed or limited on each component class.
- Fixed-scope agreement sets deliverables and timelines before any configuration work begins.
How we build
- We configure endpoint baselines in your environment to limit installed software, services and local storage.
- We set up Wazuh Security Configuration Assessment checks on monitored endpoints to flag drift from the agreed baseline.
- We deploy Fleet policies as osquery queries so each device's pass or fail state against the thin node baseline is visible.
How we hand over
- Documentation maps each SC-25 requirement to the configuration settings, policies and records that show it.
- Handover includes system design documentation, configuration settings and audit records that an examiner would review.
- Your team receives runbooks for maintaining the baseline, reviewing failing devices and handling exceptions.
How we support
- Ongoing support and continuous testing are available as a retainer after handover.
- Retainers can cover baseline updates when platform versions or your SC-25 parameter values change.
- Confirm with your independent assessor which evidence format they will accept before the scope is finalized.
