Tenable NIST 800-171 Compliance: What Tenable Proves and What It Can't

By The Defense Compliance Report Editorial Team — an independent trade publication on CMMC 2.0 and DIB compliance · Last verified September 2026

Tenable NIST 800-171 compliance has a short answer: Tenable can't make you compliant, and no scanner can. Its scans and configuration checks can support vulnerability management and selected technical safeguards. They cannot establish all 110 Revision 2 requirements. The evidence map below shows what to collect, what each artifact leaves unproved, and who still has work to do. Tenable documentation; NIST assessment objectives.

NIST SP 800-171 Revision 2 is the National Institute of Standards and Technology's special publication containing 110 security requirements for protecting Controlled Unclassified Information (CUI). Below, you'll find all 110 organized into an evidence plan, with each requirement's deduction weight in the Department of Defense (DoD) scoring method. There's also a worked example of a "green" Tenable report card that still leaves six machines without proof. Revision 2; DoD assessment methodology.

Status, checked September 23, 2026. The Department of War — the name used on the Department's current official sites — suspended Cybersecurity Maturity Model Certification (CMMC) Phase II on July 13, 2026. Its CMMC page says the program remains in Phase 1, with procurement requirements limited to Level 1 and Level 2 self-assessments during the review. The Department continues enforcing NIST SP 800-171 Revision 2 through self-assessments and select government-led assessments. Class Deviation 2026-O0025, Revision 3, dated September 3, 2026 retains that direction. We found no published Reform Task Force outcome or replacement Phase II date on the official CMMC pages and deviation index checked. A review deadline is not a restart date. Your own evidence — including what Tenable produces — still stands behind your assessment. See what the suspension changed

This page is for you if both are true:

• Your covered contractor systems must protect covered defense information under DFARS 252.204-7012, or your contract requires CMMC Level 2. DFARS means Defense Federal Acquisition Regulation Supplement. For covered systems not operated on behalf of the government, the current deviation specifies NIST SP 800-171 Revision 2; the mere presence of the clause does not make every company system part of the assessment. Current deviation, clause 252.204-7012(b).
• You run Tenable, you're pricing it, or your managed service provider (MSP) runs it for you.

It's not the right page if:

• You only handle Federal Contract Information (FCI) under a Level 1 requirement. Level 1's 15 safeguards do include finding and fixing system flaws, and a scanner can help with that (32 CFR 170.15). But you don't need a 110-row evidence map. Start with the Level 1 self-assessment checklist.
• You want the scanning rules for any tool, not Tenable specifically. Read vulnerability scanning for CMMC.

Not sure which you are? No web page — including this one — sets your CMMC level. Your contract does. Check the stated level and assessment type in the solicitation, contract, and applicable flow-down, plus any written amendment or modification. DFARS 252.204-7012 alone does not specify a CMMC level. If older language still requires a suspended assessment type, ask the contracting party to resolve it in writing; do not treat a news announcement as your contract modification. Then check whether you actually hold CUI with our FCI vs. CUI guide. July 13 implementation memorandum; September 3 deviation.

What can Tenable prove for NIST 800-171 compliance?

Tenable's scans and configuration audits produce direct technical evidence for four core workflows in this guide:

• scanning for vulnerabilities (3.11.2)
• fixing vulnerabilities based on risk (3.11.3)
• finding and fixing system flaws on time (3.14.1)
• enforcing security settings (3.4.2)

The next table adds 31 selected examples of supporting evidence. The remaining 75 requirements have their own evidence plans later on the page. These are counts of the examples in this guide, not a claim that Tenable can help with exactly 35 requirements or none of the others. A product's full capabilities depend on the edition, integrations, target systems, and checks actually run.

Here's the part vendor pages don't lead with: no scanner can tell you you're compliant. Tenable's own Nessus documentation says so. It notes that a lack of vulnerabilities doesn't mean a server is configured correctly or "compliant."

That's not a knock on the tool. It's the job description. A scanner checks machines. CMMC checks the safeguards within your assessment scope — machines, people, paperwork, and buildings (32 CFR 170.19).

“Maximum deductions” adds the largest deduction assigned to each requirement by the NIST SP 800-171 DoD Assessment Methodology, v1.2.1, Annex A. The current CMMC scoring rules are in 32 CFR 170.24. A completed assessment can run from 110 down to −203. Most scored requirements deduct 1, 3, or 5 points when not met; 3.5.3 and 3.13.11 have specific 3-point partial-implementation cases instead of the full 5-point deduction. An absent or inadequate system security plan prevents completion of the assessment; it is not a 0-point item. These aren't points Tenable earns you, and this table isn't a score.

How we sorted them. We compared the Revision 2 requirements and NIST SP 800-171A assessment objectives with Tenable’s documented scans, configuration checks, and exports. The first two groups identify concrete evidence examples; the last group keeps every remaining requirement in the work plan. “Other” means no example is mapped here, not no product capability exists. Each linked check proves only the setting or condition it actually tests.

This is our classification, not Tenable's and not the government's. Every row is below, so you can disagree with any one of them.

The four core evidence workflows

Tenable supplies direct technical evidence for scanning, patch tracking, and security settings. Three of these four requirements carry a 5-point deduction. They cannot be deferred on a CMMC assessment Plan of Action and Milestones (POA&M), the limited fix-it list allowed for a Conditional status. In general, requirements worth more than 1 point cannot go on that list; 3.13.11 has one narrow encryption exception. You can record an unmet requirement in an honest assessment, but these three must be met for an eligible Conditional or Final Level 2 status. 32 CFR 170.21(a)(2).

A 1-point item like 3.11.3 can go on an assessment POA&M only if the score is at least 88 of 110 and all other conditions are met. The rule excludes 3.1.20, 3.1.22, 3.12.4, 3.10.3, 3.10.4, and 3.10.5 regardless of weight; 3.12.4 is the system security plan (SSP). Eligible remaining items must close within 180 days of the Conditional CMMC Status Date. 32 CFR 170.21(a)(2).

31 examples where Tenable can back up part of the answer

These depend on which checks you actually run. A configuration audit tests a setting only if the audit file you chose includes a check for it. Remote Nessus compliance checks need the appropriate working credentials; a supported local agent scan uses the agent’s execution context instead. Read every row below as: “Tenable can help prove this technical part — if the selected check applies and successfully ran.” The remaining-evidence column gives examples, not every assessment objective. Nessus compliance documentation; agent-scan documentation.

In the table:

• SSH (Secure Shell) and TLS (Transport Layer Security) are encryption protocols.
• EDR means endpoint detection and response.
• FIPS means Federal Information Processing Standards.

In these 35 mapped examples, 21 requirements carry a maximum deduction of 3 or 5 points. Of those 21, only 3.13.11 has the narrow assessment-POA&M exception: encryption is employed to protect CUI, but it is not FIPS-validated, producing the specified 3-point deduction. A failed encryption requirement is not automatically eligible. 32 CFR 170.21(a)(2); 32 CFR 170.24.

The links above show vendor-documented examples, not an official Tenable-to-NIST crosswalk. A benchmark’s numerical settings are not automatically CMMC requirements. Inventory observations also need checking: Tenable notes that its Windows software-enumeration plugin can still see registry entries left after an uninstall. Plugin 20811.

Six families where a scanner cannot replace the work

These six families need work beyond a scanner, even when a technical check supports part of an objective:

• awareness and training (3.2)
• incident response (3.6)
• maintenance (3.7)
• media protection (3.8)
• personnel security (3.9)
• physical protection (3.10)

Those families involve people, procedures, facilities, and technical safeguards. A scan result cannot replace the whole process. NIST SP 800-171 Revision 2, sections 3.2 and 3.6–3.10.

Watch for this in Tenable's own reports. Tenable's documented 800-171 families include training, incident response, maintenance, and media protection. Only personnel and physical security are left out. If one of those chapters shows results, open the checks and ask what they actually test. A setting on a laptop can't show that your people were trained.

One concrete example is removable storage. Tenable publishes a USB-storage check that can support the device-control part of 3.8.7. It is included in the supporting table. It does not establish your permitted uses, handling procedures, or controls on devices the audit did not test.

The right CMMC path isn't the same for every contractor. What you need beyond Tenable depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. It might be an MSP or MSSP (managed security service provider) to run scans and patching. It might be a GRC (governance, risk, and compliance) platform to hold your SSP and POA&M, or an RPO/RP (Registered Practitioner Organization or Registered Practitioner) to check your evidence. Or it might be a CUI enclave that reduces scope when the CUI environment is genuinely separated; connected endpoints and security services may still remain in scope. The contract clause sets your level, not a checklist. Because a general answer can't resolve those for you, use The Defense Compliance Report's Find My CMMC Path tool to map your situation to the right kind of help before you request quotes — and do not submit CUI, drawings, or sensitive contract details.

Why isn't a green Tenable 800-171 report a passing score?

Tenable’s configuration-audit framework views sort results into NIST families using reference tags on each check. A CMMC assessment works differently. Each requirement is met only when every applicable assessment objective is satisfied, using evidence in final form (32 CFR 170.24(b)). A high pass rate in Tenable can sit right next to a requirement you’d fail. The same rule has specific provisions for documented enduring exceptions and appropriately managed temporary deficiencies; a red check is not, by itself, the final assessment determination.

Where Tenable's 800-171 content lives

Here's how the tags work, according to Tenable's documentation:

• In Vulnerability Management, the Compliance Framework filter reads each finding's reference information.
• In Security Center, you filter on cross-references like 800-171|3.11.* for the risk assessment family.

Two things follow from that.

First, these 800-171-filtered views require an 800-171 reference on the check. Not every check has one. On September 23, 2026, we opened a Tenable audit item for a Windows Server 2022 logon banner. It listed NIST SP 800-53 and other references, but no 800-171 reference (example). A missing tag does not make the underlying evidence useless.

Second, one finding can carry several tags. Tenable warns that reference counts in its widgets can differ from the number of actual findings. So an empty chapter means "no tagged results," not "no problems."

How to read each result

The four result labels come from Tenable's compliance export documentation. Tenable also posts plugin errors as warnings through plugin 214001 (Nessus docs).

Worked example: a green report card with six machines missing

This example is fictional. The report-card rule is real.

Say you run a 45-person machine shop. Your SSP puts 22 systems in scope:

• two file servers
• 12 desktops
• six laptops
• a firewall
• a networked copier

Your written policy says each of these 22 systems gets a supported authenticated scan every 14 days. For this example, all 22 have been determined to need that coverage; none has a documented exception or an alternative assessment treatment. That's your company's choice, not a federal number.

You use Tenable Security Center's published "NIST SP 800-171: Risk Assessment" report card. Its first check turns green when at least 80% of actively and passively detected systems were scanned in the last 14 days.

Here's what actually happened this cycle:

The card turned green because it divides by detected systems. The two machines Tenable never saw don't count against it at all.

An assessor reconciles the evidence with the actual assessment scope—not the dashboard’s denominator. In this example, the six gaps leave objective 3.11.2[b] unsupported. If 3.11.2 is determined NOT MET, that is a 5-point deduction and it cannot go on an assessment POA&M. The card also says nothing about application coverage or scans triggered by new vulnerabilities affecting those systems and applications. NIST SP 800-171A, 3.11.2; 32 CFR 170.24.

The first fix is coverage work, not automatically a bigger license:

1. Match your 22-system inventory against the scanner's target list.
2. Cover the traveling laptop through a supported, licensed Tenable agent deployment or an enforced scan window. Tenable describes agent scanning for devices that come and go; confirm the license and management path before assuming your current purchase includes it.
3. Work with the asset owner to establish safe, authorized scanning of the copier, or resolve the asset classification and an applicable documented alternative or exception. Simply writing ‘cannot scan’ does not satisfy the requirement; do not run aggressive scans against fragile equipment to fill a dashboard.
4. Re-run the scans and keep the dated results.

Don't lower the threshold to turn the card green.

Two limits on this example:

• It uses a legacy Security Center template. Tenable published it in 2016, last updated it in 2019, and says its thresholds can be customized.
• We didn't run the software. We're showing how the published rule does its math.

Older "CMMC" material to use with care

Some of Tenable's CMMC-labeled material predates today's program. Its Security Center "CMMC Operations Report," published in October 2020, still describes organizations proving compliance at one of five levels starting in June 2020. CMMC now has three levels: 15 requirements at Level 1, 110 at Level 2, and 24 enhanced requirements at Level 3 in addition to the Level 2 foundation (32 CFR 170.4). If you use an older template, verify that its checks and dependencies still fit your deployment; do not reuse its obsolete program language.

What does requirement 3.11.2 ask you to prove?

Requirement 3.11.2 says to scan organizational systems and applications periodically and when new vulnerabilities affecting them are identified. NIST SP 800-171A splits that into five checkable pieces. Every applicable objective must be satisfied; any not-applicable determination needs a documented basis (32 CFR 170.24(b)). "Periodically" has a ceiling: the CMMC rule defines it as a regular interval you choose that can't exceed one year (32 CFR 170.4).

The requirement's own discussion in NIST SP 800-171 Revision 2 fills in three details:

• It says not to overlook networked printers, scanners, and copiers.
• It says custom software may need static, dynamic, or binary analysis. Choose testing for the application rather than assuming a host scan establishes complete coverage.
• It notes that privileged access helps make scanning thorough. In practice, that's the argument for logged-in scans.

What changes what Tenable can prove

The same license can produce strong evidence or almost none. It depends on how the scans are set up. This table shows the settings that matter most.

Quick check: Open your scan policy. Is an appropriate audit file selected, and did its checks execute successfully through the configured remote credentials or supported local agent? If not, you do not yet have the configuration evidence you intended to collect.

Does Tenable put itself inside your CMMC assessment scope?

Usually, yes—when it provides security functions for your assessed environment. The CMMC rule’s Security Protection Data (SPD) definition includes information about the configuration or vulnerability status of in-scope assets. Scanning infrastructure and external services that handle that SPD must be evaluated within the assessment boundary, even when they do not handle CUI. They are assessed as Security Protection Assets (SPAs) against requirements relevant to their capabilities; this does not place every system at the vendor in your scope. 32 CFR 170.4 and 170.19.

A few more terms are useful here:

• External service provider (ESP): Outside people, technology, or facilities used for IT or cybersecurity services. The CMMC definition covers services that process, store, or transmit your CUI or SPD on provider assets; focus on the relevant service, not the provider’s entire business.
• Cloud service provider (CSP): A provider of cloud computing services under the cloud-service model used in the rule. Owning all of the underlying hardware is not the test.
• FedRAMP (Federal Risk and Authorization Management Program): The federal cloud-security program. Its current Marketplace uses “FedRAMP Certified” labels; those apply to a specific offering, not to a customer’s CMMC status.

The DoD's Level 2 Scoping Guide explains why a scanner lands in scope. It describes SPD as security information that could help an attacker if disclosed.

Think of Tenable as the building inspector's clipboard. The clipboard isn't the building. But if someone steals it, they know every weak door and window. That's why the rule puts it in scope, even though it never touches a drawing.

The rules behind this table come from the Level 2 Scoping Guide (pages 5–11) and Table 4 of 32 CFR 170.19. For the full picture, see our guides to external service provider requirements, cloud service provider requirements, and CMMC scoping.

Quick check: Where do your scan results live — on a server in your building, in Tenable's cloud, or in your MSP's tools? Write that answer into your SSP.

Can Tenable scan results contain CUI?

Scan results about in-scope assets are Security Protection Data; that label does not rule out CUI also being present. One route to check is Tenable’s file-contents audits. Tenable offers “Windows File Contents” and “Unix File Contents” compliance checks that look inside files (Nessus docs). Review actual scan output, exports, integrations, and support files—not just that feature—before sending data to a service not approved for CUI. Sensitivity alone also does not make information CUI. 32 CFR 170.4.

Is Tenable FedRAMP authorized?

One Tenable offering is. The FedRAMP Marketplace lists "Tenable Government Solutions," from Tenable Public Sector, as FedRAMP Certified. The listing shows Rev5, agency path, Class C (Moderate), certified since September 22, 2021. We checked it on September 23, 2026.

That listing covers one offering, not every Tenable subscription. Tenable's main product login is cloud.tenable.com. Ask your Tenable rep in writing whether your tenant is part of the FedRAMP offering.

Tenable's own FedRAMP product-offering document, last revised June 25, 2026, splits features into three groups:

These are selected product-group examples, not approval of every feature or integration. The document qualifies several product entries; verify the exact tenant and enabled features against its full table.

Remember the MSSP Portal line if an MSP runs your Tenable. It matters only if you need the FedRAMP environment.

If you now know where your scan data lives, the next question is who should run it. You could keep it in-house, hand defined work to an MSP, or use a CUI enclave with scanning responsibilities documented in the service agreement. That's a path decision, not a Tenable setting.

Which Tenable product fits a defense contractor?

Pick by where your CUI lives and who will run the scans, not by feature list.

• Nessus Professional runs scans and configuration audits from a single scanner.
• Tenable Vulnerability Management adds cloud management and agents.
• Security Center provides on-premises management; your deployment, integrations, and exports determine where the data actually goes.

Prices below are the dollar amounts displayed on Tenable’s purchase page on September 23, 2026, not a quote for your deployment. The page showed conflicting amounts for its two cloud products, so those rows do not present a settled price. We did not complete checkout or verify customer-specific taxes, entitlements, multi-year terms, or reseller pricing.

The cloud-price discrepancy matters. The main purchase panels displayed $3,700 for Vulnerability Management and $6,790 for Web App Scanning; embedded purchase forms displayed $3,500 and $3,578 for the corresponding 100-asset and 5-domain selections. These are conflicting displays, not a market-price range or an offer we verified at checkout. Confirm the final product, term, quantity, and amount before budgeting or paying. The Nessus Professional and Expert displays agreed at $4,790 and $6,790 for one year. Tenable purchase page.

A software subscription is only one cost. Keep implementation, recurring operation/remediation work, and any separate assessment engagement outside the license figure rather than presenting the subscription as your full compliance budget.

Three naming traps:

• Tenable Enclave Security isn't a CUI enclave. In an April 2025 release, Tenable described it as built for classified or otherwise air-gapped environments.
• Tenable Patch Management is a separate product that could help with the "correct" part of 3.14.1. We didn't evaluate it.
• Old names still show up in Tenable's resources. Tenable.io is now Vulnerability Management, and Tenable.sc is now Security Center.

Tenable at a glance

What it is. Tenable is a cybersecurity software company. It sells vulnerability and exposure management products.

What this purchase is not. A scanning subscription is not readiness consulting, a managed security service, a GRC implementation, or a formal assessment by a C3PAO (CMMC Third-Party Assessment Organization). Its software produces evidence; buying it does not assess or certify your company. We found no DoD-score calculation or SPRS-submission feature in the Tenable documentation reviewed for this guide. SPRS is the Supplier Performance Risk System. Tenable documentation; CMMC Level 2 self-assessment requirements.

What Tenable says about itself. Tenable's NIST SP 800-171 solution page says Security Center automates monitoring and assessment of many of the 800-171 technical controls. The tables above show selected evidence examples and the work those examples leave to you; they are not an exhaustive vendor capability inventory.

What to verify before you buy or renew:

• Which audit files cover your actual systems, and whether their checks carry 800-171 tags.
• Whether your tenant is commercial or part of the FedRAMP offering.
• Whether Tenable will give you a customer responsibility matrix for your SSP.
• How you'll export and retain the artifacts used in an assessment for the required six years, while setting an appropriate operational retention policy for other scan records.
• Whether agents can reach every laptop.
• The price for your real asset count.

Who it fits: Teams with someone to run it and act on what it finds, MSPs, and environments that need configuration audits.

Who it doesn't fit:

• A shop with no one to act on findings.
• A company buying it solely because it mistakenly believes FCI-only Level 1 work requires a 110-requirement evidence package. A scanner may still have operational value.
• A company buying duplicate coverage without checking what its enclave provider already scans and which responsibilities remain with the company.

Alternatives, by category (not ranked):

• other commercial vulnerability scanners
• open-source scanners
• scanning run as a service by an MSP or MSSP
• scanning included with a CUI enclave

Our vulnerability scanning guide compares these by what they can prove. Our CMMC software guide covers the wider tool stack.

How do you build a Tenable evidence package an assessor can follow?

Start from the requirement, not the report title. Decide what you’re trying to prove, run the checks that support it, keep the raw results, and write down what they don’t cover. Assessment evidence must be in final form (32 CFR 170.24(b)). The artifacts used in an assessment must be retained for six years from the applicable CMMC Status Date: 170.15(c)(2) for Level 1 and 170.16(c)(4) for Level 2 self-assessments. That is not a blanket six-year rule for every operational scan you ever run. Level 2 certification assessments have additional artifact-hashing provisions in 170.17(c)(4).

In step 4, CIS means the Center for Internet Security. DISA STIG means the Defense Information Systems Agency's Security Technical Implementation Guides. CIS publishes benchmarks; DISA publishes STIGs. Both provide hardening checklists. Choose the applicable profile and record exceptions; the benchmark’s settings do not become CMMC requirements merely because the names appear together.

Turning on the JSON export. Tenable's export documentation says the export is off by default. To turn it on:

1. Open the Policy Compliance Auditing template.
2. Go to Settings → Advanced, and set the scan type to Custom.
3. Under General → Compliance Output Settings, choose "Generate JSON result file."

Each file records the audit, the machine, the scan start and stop times, and each check's result. It also records the value found, the value expected, and the benchmark name and version. That's the raw record another reviewer can trace. To retrieve it, open the completed scan’s vulnerability results, select Compliance Export JSON (plugin 174790), and use its file attachments. It covers configuration audits only; keep your vulnerability-scan history separately.

Use this worksheet to tie each result to what it proves. Copy it, fill it in inside your own approved systems, and keep it with the export. It's a plain template. Nothing on this page collects it.

Here's the worksheet filled in for the fictional machine shop above:

TENABLE EVIDENCE WORKSHEET
Purpose: organize supporting evidence. This worksheet does not calculate a score.

Requirement and objective (e.g., 3.11.2[b]):
Standard: NIST SP 800-171 Rev. 2 / NIST SP 800-171A (June 2018)
Assessment scope and inventory version:
Tenable product, and where results are stored:
Scan type (vulnerability / configuration audit / web application):
Execution/authentication (remote success / remote failed / partial / local agent / unknown):
Audit file name, version, and profile:
Custom or gold-image changes, and who approved them:
Systems or applications expected:
Systems or applications successfully tested:
Missing, failed, unsupported, or excluded — and why:
Scan dates and time zone:
Export file name and archive location:
What this artifact supports:
What it does not establish / other evidence still needed:
Fix or risk-decision reference:
Owner and target date:
Re-scan reference:
Reviewer and review date:
Evidence state: NOT REVIEWED / MISSING / NEEDS REVIEW / COLLECTED

COLLECTED means the artifact has been gathered. It does not mean MET.
Unknown stays unknown. Never write passwords, keys, CUI, or drawings here.
Editorial template, not a government form. Template checked September 23, 2026.
Objectives source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171A.pdf
Export fields source: https://docs.tenable.com/nessus/compliance-checks-reference/Content/ComplianceDataExport.htm

Requirement and objective: NIST SP 800-171 Rev. 2, 3.11.2[b]
Assessment scope and inventory version: Fictional shop, inventory v3 (22 systems)
Tenable product, and where results are stored: Security Center, on-premises
Scan type: Vulnerability scan, logged in
Systems expected: 22
Systems successfully tested in the 14-day window: 16
Missing — and why: 4 detected but not scanned (scan window missed);
  1 laptop never detected (off-site); 1 copier never detected (unreachable segment)
What this artifact supports: coverage for 16 systems in this window
What it doesn't prove: the 6 missing systems; objectives [a], [c], [d], [e]
Owner and target date: IT lead; date to be set by the owner
Evidence state: NEEDS REVIEW

How often does this evidence need to stay current? A CMMC Level 2 self-assessment is required every three years, with affirmation after an assessment—including a POA&M closeout—and annually afterward. Scanning still follows your defined frequency and relevant-new-vulnerability trigger, and required safeguards must remain implemented between affirmations. An archive is not a reason to stop reviewing current results. 32 CFR 170.16 and 170.22.

For evidence that goes beyond Tenable, see what CMMC assessment evidence looks like. Our guides to patch management, configuration management, and asset inventory cover the process side of steps 1, 4, and 6.

What can't Tenable cover, and who usually fills the gap?

The remaining 75 requirements still need explicit evidence plans. Their maximum deduction weights add to 200 of the method’s 313 possible deductions. Some may also have useful Tenable checks or integrations; they are not classified here as “no evidence.” The table shows the work and ownership that a scanner subscription does not replace. Requirement descriptions come from Revision 2; weights come from Annex A.

See the individual weights for the other 75 requirements

These short descriptions are a navigation aid, not the full requirement or its assessment objectives. Read them with the evidence-owner table above. “Other” means not mapped to an example in this guide; it does not mean Tenable could never supply supporting evidence.

Requirements: NIST SP 800-171 Revision 2. Objectives: NIST SP 800-171A, June 2018. Deduction weights: DoD Assessment Methodology, Annex A and 32 CFR 170.24. Checked September 23, 2026.

Requirement — Work that still needs an evidence plan — Deduction if not met

Requirement	Work that still needs an evidence plan	Deduction if not met
3.1.1	Limit system access to authorized users, processes, and devices	5
3.1.2	Limit users to authorized transactions and functions	5
3.1.3	Control CUI flows according to approved authorizations	1
3.1.4	Separate duties to reduce misuse without collusion	1
3.1.6	Use nonprivileged accounts for nonsecurity functions	1
3.1.12	Monitor and control remote-access sessions	5
3.1.14	Route remote access through managed access points	1
3.1.15	Authorize remote privileged commands and access to security-relevant information	1
3.1.16	Authorize wireless access before allowing connections	5
3.1.17	Protect wireless access with authentication and encryption	5
3.1.18	Control mobile-device connections	5
3.1.19	Encrypt CUI on mobile devices and mobile computing platforms	3
3.1.20	Verify and control external-system connections and use	1
3.1.21	Limit organizational portable-storage use on external systems	1
3.1.22	Control CUI on publicly accessible systems	1
3.2.1	Make managers, administrators, and users aware of security risks and policies	5
3.2.2	Train personnel for their assigned security duties	5
3.2.3	Train personnel to recognize and report possible insider threats	1
3.3.2	Trace system actions uniquely to individual users	3
3.3.3	Review and update logged events	1
3.3.4	Alert on audit-logging failures	1
3.3.5	Correlate audit-review, analysis, and reporting processes	5
3.3.6	Provide audit reduction and report generation	1
3.4.3	Track, review, approve or disapprove, and log system changes	1
3.4.4	Analyze security impacts before implementing changes	1
3.4.5	Define and enforce access restrictions for system changes	5
3.5.1	Identify users, processes, and devices	5
3.5.2	Authenticate identities before allowing access	5
3.5.3	Use multifactor authentication for the required privileged and nonprivileged access	3–5
3.5.4	Use replay-resistant network authentication	1
3.5.5	Prevent identifier reuse for the defined period	1
3.5.6	Disable identifiers after defined inactivity	1
3.5.9	Require an immediate permanent-password change after a temporary password	1
3.5.11	Obscure authentication feedback	1
3.6.1	Establish incident handling covering preparation through recovery	5
3.6.2	Track, document, and report incidents to designated officials or authorities	5
3.6.3	Test the incident-response capability	1
3.7.1	Perform system maintenance	3
3.7.2	Control maintenance tools, techniques, mechanisms, and personnel	5
3.7.3	Remove CUI from equipment before off-site maintenance	1
3.7.4	Check diagnostic and test media for malicious code	3
3.7.5	Use multifactor authentication for nonlocal maintenance and terminate connections afterward	5
3.7.6	Supervise maintenance personnel without required authorization	1
3.8.1	Physically control and securely store media containing CUI	3
3.8.2	Limit CUI media access to authorized users	3
3.8.3	Sanitize or destroy CUI media before disposal or reuse	5
3.8.4	Mark media with required CUI and distribution markings	1
3.8.5	Control and account for CUI media during transport	1
3.8.6	Protect digital CUI during transport cryptographically unless alternative physical safeguards apply	1
3.8.8	Prohibit portable storage without an identifiable owner	3
3.8.9	Protect backup CUI confidentiality at storage locations	1
3.9.1	Screen individuals before authorizing system access	3
3.9.2	Protect systems during and after personnel transfers and terminations	5
3.10.1	Limit physical access to authorized individuals	5
3.10.2	Protect and monitor facilities and supporting infrastructure	5
3.10.3	Escort visitors and monitor their activity	1
3.10.4	Maintain physical-access logs	1
3.10.5	Control and manage physical-access devices	1
3.10.6	Apply CUI safeguards at alternate work sites	1
3.12.2	Develop and implement plans to correct deficiencies and vulnerabilities	3
3.12.4	Develop, document, and periodically update the system security plan	Prerequisite — no score without adequate SSP
3.13.1	Monitor, control, and protect communications at external and key internal boundaries	5
3.13.2	Use security-supporting architecture, development, and engineering principles	5
3.13.3	Separate user functionality from system-management functionality	1
3.13.4	Prevent unintended information transfer through shared resources	1
3.13.5	Separate public-facing components from internal networks	5
3.13.6	Deny network traffic by default and allow by exception	5
3.13.7	Prevent remote devices from simultaneous unauthorized external connections	1
3.13.10	Establish and manage cryptographic keys	1
3.13.12	Prohibit remote activation of collaborative devices and indicate their use	1
3.13.13	Control and monitor mobile code	1
3.13.14	Control and monitor voice-over-IP technologies	1
3.14.5	Perform periodic malware scans and real-time scans of external files	3
3.14.6	Monitor systems and traffic for attacks or indicators of attack	5
3.14.7	Identify unauthorized system use	3

Three notes on this table:

• The SSP is the one to start with. Without an up-to-date SSP, an assessment can't be completed at all (32 CFR Part 170, Subpart D). It's also on the rule's list of requirements that can never go on a POA&M.
• 3.14.5 isn't your Nessus scan. It calls for "periodic scans of organizational systems and real-time scans of files from external sources." That's the job of your antivirus or EDR, not a vulnerability scanner.
• Deciding who owns each row is its own exercise. Our shared responsibility matrix guide walks through it.

If most of your open items sit in the policy, people, logging, or SSP rows, a bigger scanner license won't close them. A different kind of help will.

Frequently asked questions

Can a Tenable pass percentage become my SPRS score?

No. Your score in the Supplier Performance Risk System (SPRS) comes from assessing all 110 requirements under the applicable DoD method, one requirement at a time. A Tenable pass rate counts checks or references, not completed requirements. Keep Tenable’s output as supporting evidence, and do not confuse a NIST assessment score posting with a CMMC status and affirmation. 32 CFR 170.16 and 170.24. See how SPRS scoring works.

Does a CIS Level 2 benchmark mean CMMC Level 2?

No. The two uses of "Level 2" are a coincidence. A CIS benchmark's Level 1 and Level 2 profiles describe how strict the hardening is. CMMC Level 2 is a program level tied to NIST SP 800-171 Revision 2 (32 CFR 170.14). Pick the benchmark that fits each system, then check the evidence against the actual requirements. Tenable benchmark-profile documentation.

Can every vulnerability ticket go on a CMMC POA&M?

No. The rule separates an assessment POA&M from an everyday "operational plan of action," which tracks patches and fixes as threats change (32 CFR 170.4). An assessment POA&M can list only eligible unmet requirements and must close within 180 days of the Conditional CMMC Status Date. Operational patching and newly discovered deficiencies belong in the operational plan; calling an unimplemented requirement a patch ticket does not make it MET. 32 CFR 170.21; 170.24.

Does an empty or missing result mean a requirement doesn't apply?

No. An empty filter only means no tagged results came back. A requirement is “not applicable” only when the determination has a valid, documented basis, not when a report chapter is blank. 32 CFR 170.24(b).

Are Tenable's "CMMC" reports current?

Some aren't. Tenable's Security Center "CMMC Operations Report" (October 2020) describes five CMMC levels. The program now has three. Use the current applicable audit content, identify its revision, and connect the evidence to Revision 2 requirements; an 800-171 label alone does not establish current compatibility. Tenable’s legacy report; current CMMC baseline.

If our MSP runs Tenable, does that count as our evidence?

It can. Where the MSP processes, stores, or transmits your Security Protection Data on its assets, its relevant services are in scope—not its entire business. Document those services and responsibilities in your SSP and the customer responsibility matrix, and make sure you can obtain the evidence. Level 2 Scoping Guide. Our guide to CMMC requirements for MSPs covers the rest.

Is Tenable "CMMC certified"?

No tool is. CMMC statuses belong to a contractor's information system, recorded in SPRS after an assessment (32 CFR 170.4). A scanner can help you prove parts of your program. It can't hold a CMMC status.

What we verified — and what this page doesn't test

Checked September 23, 2026:

• The Department’s CMMC pages, the July 13 implementation memorandum, the deviation index, and the complete September 3 Revision 3 deviation memorandum and attachments.
• The relevant sections of 32 CFR Part 170, including assessment criteria, POA&Ms, scoping, affirmation, and assessment-artifact retention.
• NIST SP 800-171 Revision 2 and the June 2018 NIST SP 800-171A assessment objectives.
• The DoD Level 2 Scoping Guide (v2.13).
• The point weights in Annex A of the official DoD NIST SP 800-171 Assessment Methodology (v1.2.1), and the table arithmetic.
• The FedRAMP Marketplace listing for Tenable Government Solutions and Tenable’s product-offering document, revised June 25, 2026.
• Tenable’s Nessus compliance and export documentation, compliance-framework documentation, and the vendor examples linked in the evidence tables.
• Tenable’s 800-171 report, dashboard, and report-card pages.
• Tenable’s displayed purchase-page prices, including the conflicting cloud-product amounts described above.

What we didn’t do:

• We didn’t run Tenable in a lab, execute the linked checks, or test a customer’s deployment.
• We didn’t inspect the nonpublic FedRAMP package, confirm a customer’s tenant or entitlements, or verify checkout pricing and taxes.
• We didn’t complete the Find My CMMC Path questionnaire.

The evidence grouping and machine-shop example are our own analysis. The mapped examples are not an exhaustive capability inventory or an official compliance determination.

Our methodology explains how we source and update pages. Our editorial and advertising policy explains how we handle commercial relationships.

Still not sure which CMMC path fits your company? Use The Defense Compliance Report's Find My CMMC Path tool to see which path and kind of help fit your contract, CUI, environment, and timeline — before you hire anyone.

Sources

Government sources

• Department of War CIO, About CMMC and CMMC program page — checked September 23, 2026.
• Implementing the Suspension of CMMC Phase II, July 13, 2026; Class Deviation 2026-O0025 Revision 3, September 3, 2026, including its attachments; official deviation index — checked September 23, 2026.
• 32 CFR Part 170, particularly §§170.4, 170.14–170.17, 170.19, 170.21, 170.22, and 170.24 — checked September 23, 2026.
• DoD CIO, CMMC Scoping Guide — Level 2, v2.13 — checked September 23, 2026.
• NIST SP 800-171 DoD Assessment Methodology, v1.2.1, Annex A, June 24, 2020 — official text read and weights checked September 23, 2026.
• NIST, SP 800-171 Revision 2 and SP 800-171A, June 2018 — checked September 23, 2026. Their archive/supersession status does not by itself change the revision incorporated for CMMC.
• DFARS 252.204-7012 — read with the current deviation and the clause actually incorporated into the contract, not as a replacement for contract-specific analysis.
• FedRAMP Marketplace, Tenable Government Solutions, FR1814276801 — checked September 23, 2026.

Tenable sources (company-stated)

• FedRAMP Product Offering, revised June 25, 2026 — table and column groupings visually checked September 23, 2026.
• Nessus Compliance documentation and Compliance Data Export Plugins — checked September 23, 2026.
• Compliance Frameworks and agent-scan documentation — checked September 23, 2026; verify the documentation for your deployed release.
• 800-171 Audit Details report, 800-171 Audit Summary dashboard, NIST SP 800-171 report template, Risk Assessment report card, and CMMC Operations Report — checked September 23, 2026. Legacy program descriptions and template dependencies are not current CMMC requirements.
• NIST SP 800-171 solution page and April 2, 2025 FedRAMP press release — checked September 23, 2026.
• The audit items, plugins, and report examples linked beside the 35 mapped requirements — checked September 23, 2026. A configuration example is not proof that all objectives are met or that the same check is available in every edition.
• Tenable purchase page — displayed prices and discrepancies checked September 23, 2026; checkout, taxes, reseller terms, and customer-specific quotes not verified.

About The Defense Compliance Report

The Defense Compliance Report is the independent trade publication and decision resource for CMMC and Defense Industrial Base compliance — explaining the CMMC Final Rule with primary-source citation on every claim and mapping a contractor's level, CUI scope, assessment type, and timeline to the right provider category, so DIB contractors choose the right CMMC path before they spend six figures.

We're not affiliated with the Cyber AB, the Department of Defense, the Defense Contract Management Agency's Defense Industrial Base Cybersecurity Assessment Center (DCMA DIBCAC), NIST, or any U.S. government agency. This page is educational research, not legal, contractual, or compliance advice. Confirm scope and applicability with a CMMC Registered Practitioner (RP) or a qualified federal-contracts attorney.