Specialized Assets solve a different scoping problem from Contractor Risk Managed Assets. These are assets that can process, store, or transmit CUI but are unable to be fully secured in the normal way. The Level 2 scoping rule names examples including Internet of Things devices, Industrial Internet of Things, Operational Technology, Government Furnished Equipment, Restricted Information Systems, and Test Equipment.
The practical question is not whether the device is inconvenient to secure. It is whether it fits a Specialized Asset category in the Level 2 scoping guidance and whether the organization has documented the asset, its limitations, its network relationship, and the risk-based protections used around it. That distinction matters most with OT, IoT, GFE, restricted systems, and test equipment that cannot be managed like ordinary IT.
Classify the asset by limitation, not by age or inconvenience
An old computer is not automatically a Specialized Asset. A difficult-to-manage appliance is not automatically one either. Start with whether the asset fits the specialized categories and whether it can process, store, or transmit CUI while being unable to be fully secured using the normal requirement implementation. The limitation should be inherent to the technology, mission, ownership, or authorized operating constraint, not simply the result of delayed patching.
For OT and IIoT, limitations may involve vendor-supported operating systems, safety certification, deterministic operation, maintenance windows, or embedded components that cannot run normal endpoint tools. For GFE, the contractor may face configuration or ownership restrictions established by the Government. For test equipment, the system may depend on legacy interfaces or vendor software required to support a product or program.
Write the reason down per asset or asset type. If the rationale says only 'legacy' or 'cannot patch,' it is hard to distinguish a genuine specialized constraint from a normal security deficiency. Name the function, technical limitation, owner, and the evidence supporting the classification.
Document the four things Level 2 expects
The scoping rule makes the documentation expectation concrete. Put the Specialized Asset in the asset inventory, document its treatment in the SSP, include it on the network diagram, and show that it is managed under the contractor's risk-based security policies, procedures, and practices. Those records should connect to each other.
The inventory should capture the asset identifier, type, function, location, owner, CUI capability, specialized-asset category, technical limitation, network relationship, and compensating or risk-reduction measures. The SSP should explain how the organization protects the environment given the limitation. The diagram should show the routes between the Specialized Asset and ordinary CUI Assets or security services.
Do not hide specialized systems in a generic 'lab' box. Assessment scoping depends on understanding which assets can touch CUI. A test bench with five controllers, a maintenance laptop, and a shared file-transfer workstation may have different treatment for each component. Model the real path.
Design risk reduction around the limitation
When normal endpoint controls are not possible, reduce exposure in other layers. Common design patterns include network segmentation, restrictive allowlists, brokered file transfer, jump hosts, limited administrator paths, application whitelisting where supported, physical access restrictions, monitoring at adjacent network devices, and tightly controlled maintenance procedures. The specific mix should match the asset and the risk.
For an OT device that cannot support modern endpoint protection, the surrounding switch, firewall, identity path, and maintenance workstation become more important. For test equipment that must ingest engineering data, use a controlled transfer point instead of allowing every workstation to mount the device's storage. For GFE, document which configuration decisions are contractor-controlled and which require Government coordination.
Risk-based treatment should include incident response. Decide how the asset will be isolated, preserved, investigated, and restored if suspicious activity occurs. Specialized technology often has longer replacement lead times and unusual forensic limitations, so waiting for an incident to design the response can make containment much harder.
Treat maintenance as part of the security boundary
Specialized Assets often create risk during maintenance more often than during normal operations. Vendor technicians may connect laptops, diagnostic media, serial adapters, or remote-support tools that were not part of the original architecture. The maintenance procedure should define approved tools, who authorizes the activity, how external media is checked, whether remote sessions are permitted, and what records are retained.
Map external maintenance parties to the service-provider and contract analysis. A vendor with privileged access to an in-scope device can become security-relevant even if the vendor never receives a folder labeled CUI. Record the access path and determine what contractual, scoping, or evidence obligations apply to the relationship.
After maintenance, verify that temporary accounts, firewall rules, remote sessions, and attached devices are removed or returned to the approved state. A maintenance ticket can double as evidence when it records the before/after configuration and the person who approved the work.
Work through a concrete test-equipment example
Consider a calibration workstation attached to a production test stand that receives CUI-derived parameters but runs vendor-locked software on an operating system that cannot accept the normal endpoint baseline. Calling it 'legacy' is not enough. The record should identify why the asset fits the Specialized Asset treatment, how it connects, what data it sees, what updates are impossible, and what surrounding controls reduce exposure.
Useful protections might include network segmentation, allow-listed communication paths, restricted physical access, limited administrator access, monitored jump-host administration, controlled removable media, and a defined maintenance window. The exact set should come from the actual limitation and risk, not from a boilerplate specialized-asset checklist.
Do not confuse Level 2 treatment with Level 3 treatment
The Level 2 scoping guide warns that Specialized Assets are treated differently when an organization seeks Level 3. An organization planning for Level 3 should read the Level 3 scoping requirements; do not assume the Level 2 treatment carries forward unchanged. The choice can affect how much of the specialized environment an organization wants a C3PAO to examine during its Level 2 certification assessment.
Even if Level 3 is not currently in the business plan, preserve enough architecture and risk documentation that the company can revisit the decision later. Turning a poorly documented OT or test environment into a higher-assurance assessment scope on short notice is expensive. A clean inventory and network diagram create options.
Review Specialized Assets when the mission changes
A Specialized Asset classification is not permanent just because the hardware did not change. New firmware, vendor support, a replacement platform, a different data flow, or a new network segment can change what is technically possible and how the asset should be treated. Conversely, a formerly ordinary system can become specialized when it is repurposed into a test or production function with hard operational constraints.
Set a review trigger around major maintenance, replacement, network changes, and new contract work. Ask whether the asset still needs CUI, whether the limitation still exists, and whether a stronger architecture can now isolate or replace the risky function. The most useful risk treatment is one that becomes simpler over time instead of accumulating permanent exceptions.
Finally, train engineering and operations teams on why the classification exists. They are usually the first to know when a vendor enables a new security feature, when a test workflow starts using a different file share, or when a device is replaced. Scoping stays accurate when those operational changes reach the compliance record quickly.
- Change in CUI flow or mission function
- New network connectivity or remote-management capability
- Vendor update that removes a former technical limitation
- Replacement, reassignment, or transfer of GFE/test equipment
Before you call the boundary done
- ✓Confirm the asset fits a Specialized Asset type and has a real security limitation
- ✓Record the asset in the inventory, SSP, and network diagram
- ✓Document the technical or ownership limitation
- ✓Define risk-reduction controls around the asset
- ✓Control vendor maintenance, remote support, and diagnostic media
- ✓Reassess the classification after replacement, firmware, or mission changes
Common questions
Are Specialized Assets out of scope at CMMC Level 2?
No. They are in the Level 2 assessment scope and must be documented, but the scoping rule gives them different assessment treatment from ordinary CUI Assets.
Does an old unsupported computer automatically qualify as a Specialized Asset?
No. The classification should be tied to the specialized asset definitions and a genuine inability to be fully secured, not simply to ordinary technical debt.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.