A Contractor Risk Managed Asset is not an out-of-scope asset and it is not a loophole for systems that occasionally touch CUI. Under the Level 2 scoping rule, a CRMA is an asset that can process, store, or transmit CUI but is not intended to do so because the organization has security policies, procedures, and practices in place. The asset remains inside the CMMC Assessment Scope and must be documented accordingly.
The category exists to reduce assessment burden when the organization can show a credible risk-based treatment. The regulation requires CRMAs to appear in the asset inventory, SSP, and network diagram. If the SSP sufficiently documents the risk-based treatment, the assessor generally reviews that documentation rather than assessing the asset against every other Level 2 requirement. But the assessor may perform limited checks when the documentation or other findings raise questions.
That makes CRMA classification an evidence problem, not a naming problem. A spreadsheet column that says 'CRMA' has little value unless the organization can explain what prevents the asset from being used for CUI, how the restriction is enforced, and how exceptions are detected.
Separate CRMA from CUI Asset and out-of-scope treatment
A CUI Asset actually handles CUI and is assessed against the Level 2 security requirements. Assets outside scope, by contrast, either lack a CUI/security-protection role or are separated in the manner allowed by the scoping rule. A CRMA sits between those ends: the technology could handle CUI, but documented policy, procedure, and normal practice are intended to keep CUI off it.
That capability is why it remains in scope. A normal corporate workstation on the same environment may be capable of opening a CUI file even if users are instructed not to. Calling it out of scope would require a stronger technical or architectural basis showing it cannot handle CUI or is appropriately separated. CRMA treatment instead acknowledges the capability and documents how the organization manages the risk.
Do not classify assets by convenience. Start with data flow and technical capability, then apply the category definitions. If an asset regularly receives CUI as part of the intended workflow, it is not a CRMA merely because the organization would prefer a smaller assessment burden.
- CUI Asset: processes, stores, or transmits CUI
- Security Protection Asset: provides security functions/capabilities to the CUI environment
- CRMA: remains in scope with risk-based treatment and limited assessment checks
- Out-of-Scope Asset: cannot process/store/transmit CUI, does not protect CUI, and is separated
Write the risk-based treatment so an assessor can follow it
The SSP should describe the specific policy, procedure, and technical practices that keep CUI off the CRMA. Generic language such as 'users are prohibited from storing CUI' is weak when the asset can access the same repositories as CUI workstations. Explain the control path: which repositories are blocked, which identity groups are restricted, whether data loss prevention rules apply, what removable-media policy is enforced, and how users are trained to route CUI into approved systems.
For each CRMA type, identify the business use that remains allowed. A finance workstation may access accounting systems but be blocked from the engineering CUI repository. A conference-room computer may be limited to public or internal presentation content. An unmanaged test device may be segregated from the enclave and allowed only a defined data set. These are different treatments and should not share one vague paragraph.
Describe exception handling. If an employee accidentally downloads CUI to a CRMA, who reports it, how the file is removed, whether the asset is examined or sanitized, and how the event changes the asset classification if the workflow becomes recurring? A risk-managed category is more credible when the organization has a plan for the moment the intended state fails.
Use a one-page decision record for each CRMA candidate
For each proposed CRMA, record the asset, owner, location, function, why it cannot be treated as a normal CUI Asset or Security Protection Asset, the risk-based safeguards applied, and what would cause the classification to be revisited. This turns an abstract category into a repeatable decision that another employee can understand months later.
Attach the decision to the asset inventory rather than leaving it only in a policy document. Assessors can then reconcile the inventory, SSP, network diagram, and risk treatment without guessing which asset a paragraph was describing.
- Asset identity and business function
- Reason for CRMA treatment
- Risk-based security controls and limitations
- Owner and review trigger
- Links to the inventory, SSP, and diagram
Keep the three required scope records consistent
The regulation requires CRMAs to be documented in the asset inventory, documented in the SSP, and shown on the network diagram. Those three records should describe the same environment. If the inventory says a laptop is CRMA but the network diagram puts it inside the CUI workstation segment and the SSP never explains its treatment, the category will raise questions instead of reducing assessment effort.
Add fields to the asset inventory that support the classification: asset identifier, owner, location, platform, network segment, CUI capability, intended use, CRMA rationale, enforcement mechanism, and review date. The objective is not to turn the inventory into a policy manual. It is to let a reviewer trace the classification to the control that makes the intended use believable.
On the network diagram, show enough topology to understand the relationship between CRMAs and CUI assets. The rule does not require CRMAs to be physically or logically separated from CUI assets, which is one reason the risk-based treatment matters. The diagram should make the connection path visible rather than hiding it behind a generic 'corporate network' box.
Understand what a limited check can mean
For Level 2, the scoping rule says the assessor reviews the SSP for CRMAs. If the risk-based security policies, procedures, practices, or other findings raise questions, the assessor may conduct limited checks to identify deficiencies. The rule also says those limited checks should not materially increase assessment duration or cost, but they are real assessment activity and can be assessed against CMMC security requirements.
Prepare for that possibility with narrow evidence. If the CRMA rationale depends on an identity rule, be ready to show the group assignment or access policy. If it depends on network segmentation, show the relevant rule and a test result. If it depends on endpoint restrictions, show the configuration profile and device state. The evidence should test the rationale, not recreate a full 110-requirement evidence package for every CRMA.
A useful internal challenge is to ask a reviewer to defeat the CRMA assumption. Can the user browse to the CUI repository? Can a USB drive move CUI onto the device? Can email attachments containing CUI be opened? Can a privileged administrator bypass the restriction without detection? Each answer either strengthens the rationale or identifies a real boundary weakness.
Watch for changes that silently invalidate CRMA treatment
CRMA status is especially sensitive to permissions and workflow changes. A new collaboration platform, a broad file-share group, a remote support tool, a local administrator exception, or a merger of network segments can give the asset a practical CUI path that did not exist when the classification was approved. Treat those changes as scoping review triggers.
Review CRMAs alongside access reviews and architecture changes rather than once every three years. The review can be short: confirm intended use, verify the enforcement mechanism still exists, sample the technical state, and check incident or data-loss records for evidence that CUI has appeared on the asset. Update the SSP if the treatment changes.
If the business starts intentionally using the asset for CUI, reclassify it. Trying to preserve a CRMA label after the intended use changed creates a larger assessment problem than admitting the category is no longer appropriate.
Use CRMA only when it makes the architecture more truthful
The best CRMA design is one the help desk, users, and assessor can all understand. Employees know which system receives CUI, technical controls reduce accidental crossover, and the asset records tell the same story. The category should make the assessment scope clearer, not create a complicated set of exceptions that only the compliance manager understands.
Compare the cost of maintaining the CRMA treatment with the cost of stronger separation. In some environments, a virtual desktop, dedicated enclave account, network segmentation, or blocked repository can make an asset genuinely out of scope. In others, keeping the asset as CRMA is practical. The right choice depends on what the architecture can reliably enforce, not on which label appears cheapest on a diagram.
Before finalizing the boundary, run a tabletop with operations: present realistic tasks such as receiving an engineering attachment, joining a customer portal, printing a drawing, or troubleshooting a CUI workstation. If the proposed CRMA routinely becomes the easiest tool for those tasks, the classification is fighting the business process and should be redesigned.
If the CRMA category requires a long explanation to hide that the asset routinely handles CUI like an ordinary endpoint, reconsider the classification. The category should clarify a legitimate risk-managed exception in the architecture, not become a parking place for assets that are merely difficult to bring into standard configuration.
Before you call the boundary done
- ✓Confirm the asset can handle CUI but is not intended to do so
- ✓Document the CRMA in the inventory, SSP, and network diagram
- ✓Name the policy and technical mechanisms that keep CUI off the asset
- ✓Define what happens when CUI lands on a CRMA
- ✓Test the CRMA rationale against real user workflows
- ✓Revisit the category after access, network, or platform changes
Common questions
Is a CRMA outside the CMMC Level 2 assessment scope?
No. CRMAs are inside the Level 2 assessment scope. Their assessment treatment is different from CUI Assets, but they must be documented in the required scope records.
Must a CRMA be physically or logically separated from CUI Assets?
The Level 2 scoping rule does not require that separation for CRMA classification. The organization instead documents the risk-based policies, procedures, and practices that keep CUI from being intentionally processed, stored, or transmitted there.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.