SC-25: Thin Nodes

Quick-reference card

What this control requires

SC-25 requires organizations to strip endpoint devices down to the minimum functionality and data storage needed for their designated role. Rather than deploying full workstations with local operating systems, extensive software stacks, and persistent storage, you deploy thin clients or diskless nodes that rely on centralized servers for processing and data retention.

In practice, this control means you must identify which system components should operate with minimal local capability and then enforce that constraint through architecture and configuration. The goal is to shrink the attack surface at each endpoint so that a compromised device yields little to no usable data or lateral movement opportunity. You define the specific components subject to this requirement, document them in your system security plan, and verify that each one stores only the data it absolutely needs.

Specifically, every endpoint with a full operating system, local storage, and broad software installation becomes a potential foothold for attackers. By reducing what each device can do and store, you reduce what an attacker can steal, modify, or use as a pivot point. This approach complements other system and communications protection controls by limiting exposure at the hardware and architecture layer rather than relying solely on software-based defenses.

Why it matters

Most organizations underestimate the risk that comes from allowing full-featured endpoints to proliferate across their environment. SC-25 addresses a structural weakness. The more data and capability that resides on individual devices, the larger the blast radius when one is compromised.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings during NIST SP 800-53 assessments. For organizations pursuing federal authorization or operating under frameworks that reference NIST controls, gaps in thin node implementation signal a lack of architectural discipline.

Without this control, you leave sensitive data distributed across endpoints that may lack the same monitoring, patching, and access controls applied to centralized infrastructure. That distribution makes incident response slower, forensic analysis more complex, and preventing data breaches significantly harder.

What attackers exploit

• Local data residue on endpoints. Full workstations often cache credentials, session tokens, and sensitive files locally. Attackers who gain physical or remote access to these devices can harvest stored data without needing to move laterally into the network.
• Expanded software attack surface. Endpoints running full operating systems and multiple applications present more vulnerability entry points. Each additional software package increases the patching burden and the likelihood of an unpatched flaw.
• Inconsistent endpoint hardening. Organizations with mixed endpoint types struggle to maintain uniform security configurations. Thick clients deployed across different departments often drift from baseline hardening standards, creating exploitable gaps.
• Lateral movement from compromised endpoints. Devices with local administrative tools and network utilities give attackers built-in capabilities for reconnaissance and lateral movement once they gain initial access.

How to implement

Thin node deployment isn’t a hardware decision alone. It requires coordinated changes across architecture, configuration management, and operational workflows that many organizations overlook until an audit surfaces the gaps.

For your organization

Start by inventorying your current endpoint fleet and identifying which components handle sensitive data or operate in high-risk network segments. Classify each component based on whether it genuinely requires local processing power and storage or whether it could function as a thin client or diskless node connected to centralized infrastructure.

Once you’ve identified target components, define your thin node architecture. This process typically involves selecting thin client hardware or virtual desktop infrastructure (VDI) solutions that centralize processing on servers while presenting only display output to endpoint devices. Document the approved configurations in your system design documentation and system security plan.

Implement configuration controls that enforce minimal functionality on designated components. This effort includes disabling unused ports, removing unnecessary software, restricting local storage access, and ensuring that boot images pull from a trusted, centralized source. Network boot protocols like preboot execution environment (PXE) are commonly used for diskless node deployments.

Build your evidence trail from day one. Maintain system configuration settings documentation that shows each thin node’s approved software baseline, any deviations, and the rationale for those deviations. Keep audit records of configuration changes and periodic compliance checks.

Common mistakes include deploying thin clients but failing to lock down USB storage access, allowing local caching policies that undermine the minimal-storage requirement, and neglecting to update the system security plan when new components are added to the environment.

For your vendors

When evaluating third-party vendors against SC-25, your assessment should focus on whether vendors that handle your data or connect to your systems have implemented thin node architectures where appropriate.

Ask these questions during vendor assessments:

• Which system components in your environment operate as thin clients or diskless nodes?
• How do you enforce minimal functionality and minimal information storage on endpoint devices that interact with our data?
• What is your process for approving and documenting exceptions where full-featured endpoints are required?
• Can you provide system design documentation showing your thin node architecture?

Request these evidence artifacts: system and communications protection policies that address thin node requirements, system configuration baselines for thin client devices, and audit records showing periodic verification of minimal functionality compliance.

Watch for red flags such as vendors who can’t articulate which components operate with reduced functionality, environments where every endpoint runs a full desktop operating system with unrestricted local storage, or missing documentation for endpoint configuration standards. A vendor claiming compliance without producing configuration evidence or design documentation likely hasn’t implemented this control meaningfully.

Verify vendor claims by reviewing their system design documentation for references to thin client or VDI architecture, checking configuration baselines for evidence of restricted local storage, and confirming that their data breach response plans account for the reduced data exposure that thin node architectures provide.

Evidence examples

Cross-framework mapping

No cross-framework mappings have been identified for this control.

Related controls

• SC-30 — Concealment and Misdirection adds deception techniques that complement the reduced attack surface thin nodes provide, making it harder for attackers to identify and target legitimate system components.
• SC-44 — Detonation Chambers provides a controlled environment for analyzing suspicious code, complementing SC-25’s approach of limiting what endpoints can execute locally by isolating potential threats before they reach production systems.

Frequently asked questions

What is NIST SP 800-53 SC-25

SC-25 is a NIST SP 800-53 control that requires organizations to deploy thin clients and diskless nodes with minimal functionality and minimal information storage on designated system components. It falls within the System and Communications Protection family and targets the architectural reduction of endpoint risk by limiting what each device can process and store.

What happens if SC-25 is not implemented

Without SC-25, endpoints retain full processing capability and local data storage, expanding the potential impact of a device compromise. Attackers who access a thick client can harvest cached credentials, locally stored files, and session data without needing to reach centralized systems. Auditors reviewing your environment against NIST SP 800-53 will flag the absence of minimal functionality enforcement as a gap in your system and communications protection posture.

How do you audit SC-25

Auditors verify SC-25 by reviewing system design documentation that identifies which components operate as thin nodes and confirming that configuration baselines enforce minimal functionality. They examine system audit records for evidence that designated devices restrict local storage, disable unnecessary software, and follow approved boot configurations. They also check that the system security plan documents the rationale for thin node designations and that procedures for maintaining those configurations are current.

What is the difference between thin clients and diskless nodes

Thin clients are endpoint devices built with limited local processing power that depend on a centralized server for most computation and data storage. Diskless nodes take this concept further by eliminating local persistent storage entirely, booting from the network each session. Both approaches satisfy SC-25’s requirement for minimal functionality and minimal information storage, but diskless nodes provide stronger assurance that no sensitive data persists on the endpoint after power-off.