SC-40 Wireless link protection: requirements and evidence

What SC-40 wireless link protection requires and when it applies

SC-40 requires an organization to protect defined wireless links, both external and internal, from defined types of signal parameter attacks. You are most likely reading this because your tailored SP 800-53 baseline or an overlay pulled SC-40 in, or because an assessor raised it against a system that has radio links you did not think of as network connections. The control is not in any SP 800-53B baseline. It applies only when someone selects it through tailoring or an overlay, and Appendix C of SP 800-53 Rev. 5 lists it as a control the system implements. The organization decides what the protected links are, which attack types it is defending against, and the parameters that define the protection. In Release 5.2.0 the control carries six organization-defined parameters and four control enhancements, so the work is largely a set of decisions you must document rather than a checklist someone hands you.

The risk behind the control is that radio links can be disrupted or imitated without anyone gaining access to a wired network. Jamming denies service on a link, spoofing injects false signals or impersonates a legitimate transmitter, and other signal-based attacks can intercept or manipulate traffic at the radio layer. Before you size any protection, confirm with your architects which wireless links exist, including Wi-Fi access points, cellular or private LTE, point-to-point microwave, satellite terminals, industrial radio, and wireless sensors or handhelds that connect to the system. Ask whether each link is external (crossing the system boundary) or internal (inside it). Those two lists are the scope the assessor will test against.

Then decide which attack types each link must be protected from and what the protection parameters are. Record these choices in the system security and privacy plan along with the reasoning, because an assessor will test the decisions as much as the controls that follow from them. Also check whether SC-40 is related to AC-18 (wireless access) and SC-5 (denial-of-service protection) in your baseline, since the evidence for those controls will overlap with what you show for SC-40. Confirm the exact parameter and enhancement wording against the NIST SP 800-53 Rev. 5 catalog for your release before you finalize the plan, because parameters are the first thing an assessor will read.

Which wireless links and systems fall under SC-40

SC-40 only applies once an organization selects it, so the first work is deciding whether it is in scope at all. The cards below cover the decisions that change the work: the link types in the boundary, the internal versus external split, FedRAMP class, and how the neighboring controls AC-18 and SC-5 overlap with it.

Confirm SC-40 is selected

SP 800-53B does not assign SC-40 to any baseline, so a system only carries it after the organization selects it through tailoring or an overlay. Record that selection and its rationale in the system security and privacy plan. If no one selected it, an assessor will treat the control as out of scope and ask why wireless links were never considered. Ask the authorizing official to confirm the decision in writing.

External versus internal wireless links

SC-40 asks for protection of defined external and internal wireless links, so the organization must define both sets. External links include radio or cellular connections that cross the system boundary, such as remote sensor backhaul. Internal links include Wi-Fi access points and Bluetooth peripherals inside a facility. Build a list of each link with its endpoints so the assessor can match it against the wireless network diagram.

Wi-Fi, cellular, Bluetooth and radio

Each wireless technology has its own threat model, so decide which ones fall inside the defined boundary. Wi-Fi and Bluetooth are common in offices and clinics, while cellular modems and industrial radio often sit in remote or operational environments. Inventory every radio interface, including devices that were added without procurement review. Anything left out of the inventory is still a wireless link an assessor can find during testing.

Industrial and OT wireless

Industrial wireless, such as sensor networks and wireless control links, may carry safety or availability functions that make jamming and spoofing more serious. These links often fall outside standard IT inventories because operations teams manage them. Confirm with the operations owner which devices transmit, which signal parameters they use, and whether any link carries control traffic. Document the findings in the system design documentation so the assessor can review them.

FedRAMP class and Rev5 baselines

FedRAMP Rev5 baselines do not require SC-40 at Class B, C or D, so a cloud service offering at those classes does not inherit the requirement by default. An agency or sponsor may still add it through a parameter or overlay, so confirm the authorization package and any agency-specific requirements before scoping it out. Keep the FedRAMP control reference with the system's documentation to show the decision was based on the current rules.

Interaction with AC-18 and SC-5

The catalog lists AC-18 and SC-5 as related controls to SC-40. AC-18 governs wireless access, including who may connect and how, so the access decisions in AC-18 determine which links exist in practice. SC-5 covers denial-of-service protection, which overlaps with jamming scenarios. Trace each wireless link to its AC-18 authorization and its SC-5 response so one control does not leave a gap the others assume is covered.

How an assessor tests SC-40 and what evidence they request

This table breaks down the two SP 800-53A determination statements for SC-40 by assessment method, object and evidence. Use it to see what an assessor will examine, whom they will interview and where wireless link protection assessments usually stall.

Assessment element	What the assessor does	Evidence to prepare	Where it usually fails
Determination statement 1 (wireless links identified and protected)	Examines the list of internal and external wireless links against the system design, then confirms the defined signal parameter attacks are the ones the links must withstand	Current list of internal and external wireless links, system design documentation showing where each link sits, and the defined list of signal parameter attacks	The link list omits newly added access points, bridges or sensor links, so the protection claim covers only part of the wireless footprint
Determination statement 2 (protection from defined attacks implemented)	Tests whether the selected protections work against each defined attack type, using the organization's own parameters for attack types	Test plan and results for each attack type, configuration evidence for the protective mechanisms, and references to the attack sources used	The attack list does not match the design, or the test shows protections were never exercised against the attack types the organization defined
Examine method	Reviews wireless network diagrams, the link inventory, the attack list or referenced attack sources, and system design documentation for consistency	Dated wireless network diagrams, versioned link inventory, attack list with source references, and design documents with revision history	Diagrams and design documents disagree on link paths, or the attack list carries no date, owner or source reference
Interview method	Speaks with the wireless network engineer, system owner and the staff who maintain the link inventory and attack list	Named owners for the link inventory and attack list, and a short description of how changes to wireless links are recorded	Staff describe a link or attack class that the documents never mention, showing the paperwork lags the actual configuration
Test method	Verifies, where practical, that the protections respond to the defined attack types, such as jamming or spoofing scenarios in a controlled setting	Test scope, test records, observed results and remediation for any failed test, handled under the organization's own test rules	No test scope exists, or testing covers only one link while the design lists several external and internal links
Outdated inventory or attack list	Compares the inventory date with recent design or configuration changes and flags mismatches as findings	Change records showing when each wireless link was added, moved or removed, and when the attack list was last reviewed	A new wireless link appears in configuration or on the network but is absent from the diagram and inventory
Parameter and enhancement scope	Confirms the organization set its six parameters and decided which of the four enhancements apply to its environment	Parameter settings with rationale, and a documented decision for each enhancement that was not selected	Parameters remain at placeholder values or enhancements are silently skipped without a recorded reason
Applicability check	Confirms SC-40 was selected through tailoring or an overlay, since no SP 800-53B baseline assigns it	Tailoring record or overlay selection showing SC-40 was chosen and why, along with the system's wireless footprint	The system has wireless links but SC-40 was never selected, so the assessor has no procedure to apply

Implementing SC-40 step by step

This sequence turns SC-40 from a control name into a documented, tested set of wireless link protections that an assessor can trace from selection through review. Each step produces a artifact that the next step depends on.

Confirm selection through tailoring
Start by checking whether SC-40 is in your system's baseline or was added by tailoring or an overlay. SP 800-53B does not assign SC-40 to any security or privacy baseline, so in most cases the organization or the authorizing official must select it deliberately and record why. Confirm the selection against the system's control baseline and any overlay your authorizing body requires, and confirm with your authorizing official whether any FedRAMP Rev5 class you target applies it. The output is a tailoring record that names SC-40, its organization-defined parameters and the reason for selection. Without that record, the later steps have no authority behind them.
Inventory every wireless link
Build a list of the wireless links that cross the system boundary (external) and those that exist inside it (internal). Include Wi-Fi access points, cellular or radio backhaul, Bluetooth-enabled devices, wireless sensors, industrial radio and any wireless link between buildings. Owners of facilities, network operations and endpoint teams usually hold the input, and a wireless site survey or controller export helps confirm what is actually deployed. The output is a link inventory with each link's owner, location, frequency or technology, and whether it is external or internal. Assessors examine this list directly, so confirm it matches the wireless network diagram.
Define the attacks and parameters to protect
Specify the signal parameter attacks the system must defend against, such as jamming, spoofing and other signal-based interference, and the parameters that each protection must cover. The control leaves these choices to the organization through its organization-defined parameters, so record the decision rather than copying a generic list. Use threat intelligence, vendor advisories, the operating environment and any published sources you rely on as references. The output is an attack list where each entry names the attack type, the links it could affect and the source that justified it. Keep the source references, because assessors check that the list traces back to something.
Choose protections for each link
Match each inventoried link to the protections that address the attacks listed for it. Options include frequency and channel management, authenticated and encrypted links, link-layer monitoring for interference, redundant or alternate paths and physical restrictions on where links can reach. Decide which of the four SC-40 enhancements apply, for example the electromagnetic interference or reduced detection potential enhancements, and record the reason for each one you skip. Confirm with the wireless equipment vendor which protections the hardware and firmware actually support, because a control that the device cannot perform will not pass testing. The output is a per-link protection matrix that ties each link to its attacks and its chosen protections.
Document the wireless design
Write the system design documentation and wireless network diagram that show how the chosen protections sit in the architecture. Include the link inventory, the attack list with sources, the protection matrix, configuration baselines for wireless controllers and access points, and the locations where monitoring feeds into the security information process. Assign an owner to each protection so the design can be maintained. The output is a design package that an examiner can read without interviewing the builders, and it should match the system security plan entries for SC-40.
Test the protections
Verify that each protection works as documented. Testing can include reviewing configuration exports against the baseline, observing that encrypted links reject unauthenticated devices and running controlled interference or spoofing tests where the environment and safety rules allow. Testing that affects live radio spectrum requires coordination with the regulator and with facility owners, so confirm those approvals before starting. Interview the operators who respond to wireless alerts. The output is a test record for each link that states the method, the result and any defects, which feeds the assessment report. Schedule retests after configuration changes.
Set up ongoing review
Establish how the SC-40 design is reviewed and kept current. Define triggers for review, such as new wireless links, hardware replacement, a new threat advisory or a significant change to the boundary, and assign who reviews the link inventory and attack list. Feed review findings into the plan of action and milestones and into continuous monitoring so gaps are tracked to closure. The output is a review schedule, a change trigger list and a log of past reviews, which together show an assessor that SC-40 is operated rather than documented once. Ask your assessor which review frequency they will expect for your system.

How the organization-defined parameters and enhancements shape the work

SC-40 has six organization-defined parameters and four control enhancements in Release 5.2.0, and none of those enhancements is assigned to an SP 800-53B baseline. That combination means the control's requirements are whatever the organization defines, and every enhancement it adopts is a decision it must document and justify. The parameters are where the work starts. They fix which external and internal wireless links are in scope, which types of signal parameter attacks the system must protect against, and the related values that turn the abstract requirement into something testable. Wording for each parameter should be read from the Release 5.2.0 catalog rather than from summaries, because the exact text governs what an assessor will check. Confirm the current parameter list against the OSCAL catalog before drafting.

An assessor will not accept a parameter value that exists only in a policy statement. SP 800-53A checks SC-40 against design documentation, wireless network diagrams and the list of internal and external wireless links, so each defined value must match what the diagrams and configuration actually show. For example, if the organization defines a parameter covering the attack types it protects against, the design file should name the controls that address each attack type, and the inventory of wireless links should reconcile to the diagrams. Gaps between the parameter values and the architecture are the most common reason an implementation looks complete on paper and fails in testing. Ask the team that owns the wireless design to walk through each value against a current diagram before the assessment starts.

Because no enhancement is baseline-assigned, the four enhancements should be treated as an explicit selection exercise. For each one, record whether it is adopted, partially adopted or not applicable, the reason, the system component it applies to and the owner who accepts the residual risk. The enhancements relate to electromagnetic interference protection and to reducing detection potential, so a decision to skip one should reflect the actual threat model and the operating environment, not a convenience. Assessors will look for this reasoning in the system security plan and in the plan of action and milestones for anything deferred. Rationale written at selection time is far cheaper to produce than rationale reconstructed during an assessment. Confirm the exact enhancement titles and their parameters in the catalog before writing the selection record.

Evidence that passes an SC-40 assessment

SP 800-53A assesses SC-40 by examining design documentation and link inventories, then testing whether the protections work. The cards below cover the artifacts an assessor expects, and each one needs a named owner and a refresh trigger so it still matches the system at the next assessment.

Wireless network diagrams

Diagrams show every wireless segment, access point, controller, bridge and point-to-point link, with the boundary where each one meets wired infrastructure. An assessor compares the diagram against the system as it runs, so a diagram that omits a radio found during a site walk fails the examination. Update the diagram whenever a radio is added, moved or retired, and tie the review to change tickets rather than a calendar date alone.

Internal and external wireless link list

This inventory names each wireless link, its endpoints, its frequency band, whether it crosses the system boundary and the owner responsible for it. Splitting the list into internal and external links matches how the control is written and lets the assessor test each group separately. Generate the list from the controller or network inventory where possible, then reconcile it against the diagrams each quarter.

Signal parameter attack list with sources

The organization defines which signal parameter attacks it protects against, such as jamming, spoofing or interception, and records the source for each entry. The source may be a threat report, an internal test finding or a vendor advisory. Keep the list dated and versioned, because an assessor asks why each attack type was chosen and whether the choice still reflects current threat information.

System design documentation

Design documents explain how each protection is meant to work, including the chosen radio security modes, key handling, rogue access point detection and the reasons for any gaps. This is the record an assessor reads before testing, so it must describe the system as built. Store it under configuration control and require an update whenever the design changes, including design changes made by a managed service provider.

Configuration evidence of protections

Exports of controller and access point settings show the protections are active, such as encryption and authentication modes, transmit power limits, rogue detection thresholds and management interface restrictions. Capture the configuration with timestamps and hashes so an assessor can confirm the export came from the running system. Recheck the exports after firmware upgrades, since vendor defaults can change during an update.

Test results and remediation records

Test records show that defined jamming, spoofing and rogue device scenarios were run against the wireless links, what was observed and how each finding was closed. Assessors use these results to decide whether the protections work, not only whether they are configured. Schedule repeat tests after significant wireless changes, and confirm with your assessor which test scope and frequency they will accept before testing begins.

What meeting SC-40 costs in money and effort

This table breaks down the cost and effort components of meeting SC-40 Wireless link protection, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written scope and quote request, since no price or duration for SC-40 work is supplied here.

Cost component	One-time or recurring	What drives it and what to ask for in a quote
Link inventory and boundary design	One-time, revisited on change	Number of wireless links, sites and interfaces. Ask the partner to list the deliverables: link inventory, wireless network diagrams and design documentation.
RF and wireless testing	One-time per assessment cycle	Number of links, signal types tested and whether testing is run in production or a lab. Ask for the test method, equipment used and who holds the results.
Signal parameter attack list and rationale	One-time, updated when threats change	Depth of threat analysis for jamming, spoofing and signal-based attacks. Ask how sources for attacks are selected and how the list is kept current.
Evidence upkeep	Recurring	Frequency of configuration changes, new sites and review cycles. Ask who maintains the diagrams, link lists and test records between assessments.
External testing or independent review	Periodic, when commissioned	Scope of wireless testing performed by a third party and whether it is used as input to the assessor. Ask for the written scope before work starts.
Assessor sampling and review	Recurring per assessment	Number of links and documents the assessor samples. Confirm with the independent assessor how they will select samples, since they issue any findings.
Open-source platform licensing	Reduced where self-hosted tools replace paid products	Self-hosted open-source tools can lower license spend, but the organization still pays for setup, hardening and maintenance. Ask which components carry license fees and which do not.

Who does what for SC-40

The organization owns SC-40. It decides whether the control applies, sets the values for the control's organization-defined parameters, and remains accountable for every wireless link inside the authorization boundary. Because SP 800-53B does not assign SC-40 to any baseline, the first decision is whether the system's risk picture justifies selecting it through tailoring or an overlay. Only the organization can make that call, and it should record the reasoning in the system security and privacy plan.

Selection and tailoring: Decide whether SC-40 is in scope and document the basis for that decision so an assessor can trace it.
Parameter values: Set the six organization-defined parameters, including which wireless links count as internal or external and which signal parameter attacks the system must withstand.
Attack list: Own the list of signal parameter attacks, or the sources the organization uses to build it, because assessors ask for this list by name.
Wireless architecture: Approve the wireless network diagrams and system design documentation, and keep them current when access points or links change.

Confirm that a named owner can answer which wireless links exist today and which threat list those protections were designed against.

Where SC-40 assessments usually fail

SC-40 is short, but its two determination statements turn on evidence that many programs never produce: a current picture of wireless links, a documented threat list, and proof that protections work against the parameters the organization defined. The gaps below cluster around inventory, rationale and scope, which are the first places an assessor looks.

No current wireless link inventory

SC-40 is tested against defined external and internal wireless links, and an assessor will check the list against the wireless network diagrams and system design documentation. Programs often hold a diagram from the original build that no longer matches access points, bridges, point-to-point links or industrial radios added later. Check that every link is named, owned and tied to a diagram revision, and that the list is refreshed when the network changes.

Attack list without sources

The control refers to defined types of signal parameter attacks, and the assessment expects either the list itself or references to the sources used to build it. A list of generic attack names with no origin, date or link to the organization's threat intelligence gives the assessor nothing to verify. Record which jamming, spoofing or signal-based sources informed each entry, and who reviews the list.

Protections never tested against parameters

Organizations often describe radio protections such as frequency management, encryption or monitoring for detecting interference, but never show that they respond to the parameters the organization defined. Test each protection against the specific signal parameter attacks on the list, record what was observed, and retain the results. A design statement without a test result will not satisfy the test method.

SC-40 selected without rationale

SC-40 is not in any SP 800-53B baseline, so its presence in a system security plan should follow from a tailoring decision. When the control is selected with no written reason, assessors question whether the risk was considered at all. Document the threat or mission driver that justified selection, the enhancements chosen or rejected, and the parameters set, and link that record to the plan of action where anything is deferred.

Wireless access missing from AC-18

SC-40 sits beside AC-18 in the catalog, and the two are often assessed by different owners. Wireless access authorization, configuration and usage restrictions under AC-18 may cover corporate Wi-Fi while leaving out the radio links that SC-40 covers, such as building-to-building bridges or sensor networks. Compare the AC-18 scope with the SC-40 link inventory and confirm that each wireless link appears in both.

SC-40 questions buyers ask before bringing in help

Is SC-40 wireless link protection required by default under NIST SP 800-53?

No. SC-40 is not assigned to any SP 800-53B security baseline (low, moderate or high), so it applies only when an organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system. Its four enhancements are also not assigned to any baseline. Organizations should check whether a contract, agency or authorizing body has added it to their control set before planning work. FedRAMP's Rev5 baselines also do not require SC-40 at Class B, C or D.

How much effort does SC-40 take, and what drives it?

Effort depends mostly on how many wireless links the system uses and how many of them are external or internal. The control's organization-defined parameters must be set, and the team must identify which signal parameter attacks the system is designed to resist. Work usually includes listing wireless links, reviewing network diagrams and documenting protections. Effort rises with the number of sites, the number of wireless technologies and the amount of legacy equipment. Ask any provider for a written breakdown of inventory, design review, configuration and evidence work, and state which items are one-time and which recur at each reassessment.

How long does SC-40 implementation take?

Timing depends on the written scope. The main variables are the number of wireless links to document, whether hardware or configuration changes are needed, and how quickly the organization can supply design documentation and approvals. A narrow scope covering a few documented links will take far less time than a multi-site environment with uncatalogued wireless equipment. Do not accept a duration without a defined list of deliverables, dependencies and review points, and confirm which steps depend on your own change approval process.

What does the team need to provide for an SC-40 engagement?

The organization needs to provide access to people and records that describe the wireless environment. The assessor will look for wireless network diagrams, a list of internal and external wireless links, a list of signal parameter attacks or references to the sources used to identify them, and system design documentation. Someone must own the decisions on defined parameters and accept residual risk. Engineers should be available to confirm how each wireless link is configured. Missing or outdated diagrams are the most common reason these reviews stall.

Can we implement SC-40 in-house without an outside partner?

Often yes, if the team has network and wireless engineering skills and clear ownership of the control. Internal staff can inventory links, set parameters, document design decisions and collect evidence. An outside partner is most useful when the team lacks wireless security experience, when the environment is large, or when they want an independent review before an assessment. Whichever path you choose, the organization remains accountable for its controls. DeployOpen can prepare systems, configurations and evidence under a fixed written scope, but it does not assess or certify them.

Who issues the assessment result for SC-40?

Only an independent assessor issues the assessment result. Under NIST's assessment procedures in SP 800-53A, the assessor examines documents, interviews staff and tests the implementation against two determination statements for SC-40. In federal contexts, the authorizing official makes the risk decision based on that assessment. An implementation partner prepares the system, documentation and evidence but does not produce the assessment report, attestation or any certificate. Confirm with your contracting body which assessor they accept and what format they expect the results in.

Which open-source tools help produce SC-40 evidence?

Open-source tools mainly help with inventory, configuration records and evidence storage. Teams commonly use network discovery and documentation tools to build the list of wireless links, configuration management systems to keep settings under version control, and self-hosted ticketing or wiki platforms to keep design decisions and parameter records. Evidence from these tools must still be reviewed for accuracy. Confirm with each tool's maintainers which features they support and whether they fit your environment before depending on them for assessment evidence.

What should a quote for SC-40 work include?

A quote should list the written scope, the systems and wireless links covered, the deliverables and the acceptance criteria. It should separate one-time work, such as the initial inventory and design review, from recurring work, such as periodic review and evidence refresh. Ask how the provider handles changes to the scope, what the organization must supply, and which items the organization must complete itself. DeployOpen provides a quote after a written scope is agreed. It does not publish a price list, and it does not estimate prices before that scope exists.

How DeployOpen prepares SC-40 evidence

DeployOpen starts SC-40 work with a fixed-scope written agreement that names the wireless links in scope, the assessment boundary, the organization-defined parameters the client has chosen for the control, and the enhancements the client has selected through tailoring. Because SC-40 is not assigned to any SP 800-53B baseline, the first decision is whether the client has selected it at all, and that choice should be recorded in the system security and privacy plan before any engineering starts. The agreement also sets who signs off each deliverable, who holds the keys to the environment, and which findings go to the client's own remediation tracker. DeployOpen does not decide whether the control applies, and it does not issue audit reports or certifications. The organization owns its controls, and its independent assessor decides whether the evidence supports the findings.

Inside the client's own environment, the work builds the two examine objects that carry most of the weight for the control: a wireless network diagram and a list of internal and external wireless links, with each link tied to its protection mechanism. The team then compiles the list of signal parameter attacks the client has decided to defend against, or the references to sources that define them, and checks the design documentation against that list. Protection tests cover jamming, spoofing and other signal-based attacks where the client has chosen to test them, and each test records the configuration under test, the expected result, the observed result and the person who ran it. Test evidence is stored with the client, not with DeployOpen, and the client confirms the assessment method with its assessor before testing starts. Where the client's wireless estate is small or absent, the package should say so clearly rather than inflate the inventory.

The handover package contains the link inventory, the attack list, the design documentation, the test records and a short mapping from each item to the two SP 800-53A determination statements, so that the client and its assessor can trace every claim to a file. Clients should confirm two things before accepting it: that the assessor agrees with the chosen attack list and test method, and that the link inventory matches what the network team sees in its own tooling. The NIST SP 800-53A Rev. 5 publication is the natural reference for the assessor. Ongoing changes to wireless links should be routed back through the client's change process, and DeployOpen can support that work under a separate written retainer if the client asks for it.

SC-40 Wireless link protection