Adlumin CMMC Review: What N-able's MDR Actually Covers — and What It Doesn't

By The Defense Compliance Report Editorial Team Last reviewed: August 2026 · Last verified: August 27, 2026

Editorial research — not formally reviewed by a CMMC Subject Matter Advisor. Verify scope and applicability with a CMMC Registered Practitioner or qualified federal-contracts attorney before acting.

How we evaluated this: This is a documentary review. We read N-able's published product pages, package tables, CMMC solution pages, blog posts, security updates, and press materials; N-able's SEC filings; CISA's Known Exploited Vulnerabilities catalog; and the governing text at 32 CFR Part 170, NIST SP 800-171 Rev. 2, and DFARS 252.204-7012 — and we checked them against each other. We are not Adlumin customers. We did not test the product, and N-able did not participate. Every vendor claim below is labeled as a vendor claim.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or marketplace-status verification. We have no compensation relationship with N-able, Adlumin, or Coalfire. No link on this page is an affiliate or sponsored link.

---

If you're searching for an Adlumin CMMC review, start here: Adlumin is not an independent company anymore. N-able, Inc. (NYSE: NABL) acquired Adlumin, Inc. on November 20, 2024, and N-able's SEC filing says Adlumin became an indirect wholly owned subsidiary. Adlumin now appears in market as an N-able security-operations product line.

The verdict: Adlumin can carry real weight in a CMMC Level 2 program — audit-data collection, continuous monitoring, detection, and incident support. But buying it does not make your environment compliant, and it does not make the service disappear from scope. If the service processes Security Protection Data without CUI, 32 CFR 170.19(c)(2) puts the services it provides inside your assessment scope and assesses them as Security Protection Assets. N-able says the larger point itself: N-central and Adlumin MDR/XDR are not themselves CMMC-compliant solutions. N-able's public Adlumin mapping points to roughly 5 of the 14 NIST SP 800-171 Rev. 2 requirement families. The other nine still need an owner — you, your MSP, your readiness provider, or another product.

The answer changes based on four things: which package you buy; which exact data fields leave your environment; whether you also deploy the on-premises N-central CMMC edition; and whether your current solicitation, contract, or flow-down calls for Level 1 Self, Level 2 Self, or another assessment path.

Here's what makes this worth your next eight minutes. N-able's CMMC pages still tell Level 2 buyers to plan around third-party assessment language, while N-able's own July 2026 article reports that CMMC Phase II was suspended. The Department's implementation memo goes further: during the suspension, requiring activities may designate only Level 1 Self or Level 2 Self, and active Level 2 C3PAO or Level 3 requirements must be amended or modified on the memo's schedule. Both versions of the story are live. We dated them. We'll show you both, and what they mean for money you might be about to spend.

---

Adlumin CMMC review: quick verdict

Definitions, once, so the rest reads clean. CUI is Controlled Unclassified Information — sensitive but unclassified information that must be safeguarded under applicable government rules and contract terms. FCI is Federal Contract Information, a lower tier. C3PAO means CMMC Third-Party Assessment Organization — the organization authorized to conduct a Level 2 certification assessment when that path applies. RPO/RP means Registered Provider Organization / Registered Practitioner — the advisory side of the Cyber AB ecosystem. MSSP means Managed Security Service Provider. SPRS is the Supplier Performance Risk System; it stores NIST SP 800-171 assessment records and CMMC records, including results and annual affirmations where applicable. DIBCAC is the Defense Contract Management Agency's Defense Industrial Base Cybersecurity Assessment Center. MDR is Managed Detection and Response — a service where outside analysts monitor and help respond to security events.

---

What did we actually verify?

Verified from primary or current first-party sources on August 27, 2026:

• N-able's acquisition of Adlumin, Inc., the closing date, the subsidiary structure, the consideration, and the acquisition-related employee count — from N-able's Form 10-K
• The current Adlumin MDR package table, feature by feature, including 30-, 30-, and 90-day data-retention periods — from the N-able Adlumin MDR product page
• A live N-able packaging page that uses a different package naming scheme — MDR Base, MDR Complete, and MDR Plus — from the Adlumin Packaging Guide
• N-able's written CMMC disclaimer — from its CMMC solution page
• N-able's statement that CUI retrieval is disabled by default — from its November 12, 2025 product-management article
• N-able's public description of a Coalfire attestation involving N-central for CMMC Compliance — from the N-able attestation resource page
• The N-central August 2026 incident chronology and fixed builds — from N-able's August 10, 2026 security update
• The current CISA Known Exploited Vulnerabilities status for the N-central CVEs — from the CISA KEV catalog
• The Security Protection Asset and External Service Provider scoping rules — from 32 CFR 170.19
• The governing Level 2 requirement set — NIST SP 800-171 Rev. 2, not Rev. 3 — from 32 CFR Part 170 and NIST's Rev. 2 publication record
• The 72-hour reporting and 90-day preservation obligations — from DFARS 252.204-7012
• The current Phase II suspension mechanics — from the DoD CIO CMMC page and the Department's Implementing Suspension of CMMC Phase II memorandum

What we could not verify — and are not claiming: current pricing in dollars; a current Adlumin or N-able C3PAO/RPO/RP Marketplace status; a FedRAMP authorization or package ID; whether Adlumin is inside the scope of any N-able ISO/IEC 27001 certificate; the full scope, signer, and date of the gated Coalfire letter; where Adlumin stores and processes customer data; its current subprocessor list; whether any personnel restrictions apply to analysts; whether the configurable-controls capability roadmapped for Q4 2025 shipped; and whether the current CMMC-specific report is accurate, available, and still mapped to Rev. 2. Every one of those is a question in the evidence request below.

---

Is Adlumin still Adlumin, or is it N-able now?

Answer capsule: Adlumin is a security-operations product line owned by N-able, Inc. (NYSE: NABL). N-able acquired Adlumin, Inc. on November 20, 2024, and its SEC filing says Adlumin became an indirect wholly owned subsidiary. Current Adlumin products and documentation live under n-able.com as Adlumin SecOps.

This sounds like trivia. It isn't. It changes what you're evaluating, who signs your contract, which service names belong in your System Security Plan, and which documents an assessor will ask for.

Here's the thing about researching Adlumin in 2026: a large share of what you'll find describes a company that stopped operating independently in November 2024. The cleanest public size marker we could verify is not a current customer count or current Adlumin headcount. It is N-able's acquisition snapshot: N-able reported 1,773 employees as of December 31, 2024, and said 131 employees joined N-able in connection with the Adlumin acquisition, all full-time in the United States. That is a dated acquisition fact, not a claim about how many people support the product today.

The company you would be buying from or contracting through is part of a publicly traded software group with products spanning endpoint management, backup, security, remote support, and security operations. Do not assume the product brand, legal subsidiary, contracting entity, support entity, and data-processing entity are all the same name.

The two-brand ledger

The last row deserves a second look. The entity on your signature page may not be the same name you use casually in your SSP. Ask which entity contracts, which entity operates the SOC, which entity processes your data, and which entity makes the incident-response commitments. Get the answer in writing. It takes one email.

One more thing to know before you go hunting. If you find an old Adlumin page describing CMMC as a five-level maturity model across 17 domains, you're reading CMMC 1.0 material. The current CMMC Program Rule establishes three levels, and Level 2 is tied to the 110 requirements across 14 families in NIST SP 800-171 Rev. 2. Anything organized around five levels and 17 domains predates the controlling program.

---

Does using Adlumin put my company in CMMC scope?

Answer capsule: Usually, yes — but the exact classification depends on the data. Under 32 CFR 170.19(c)(2), an External Service Provider that processes, stores, or transmits Security Protection Data without CUI is in the Level 2 assessment scope, and the services it provides are assessed as Security Protection Assets. If the service processes CUI, the rule changes: a cloud service provider must meet the applicable DFARS 252.204-7012 FedRAMP requirements, while a non-cloud ESP's services are assessed as part of the contractor's assessment. Turning off file-content retrieval may reduce CUI exposure. It does not, by itself, prove which category applies.

This is the misread that costs people at the worst possible moment. The logic sounds airtight: the SOC never opens our CUI files, so the SOC isn't part of our assessment. The rule does not work that way.

Security Protection Data is the data used to protect your environment. Logs, alerts, vulnerability findings, identity events, configuration data, and administrative telemetry can describe your CUI systems and how they are defended. A service that processes that data may be protecting the CUI environment even when nobody opens the controlled drawing itself.

Give N-able credit where it's earned: in its November 2025 CMMC article, the company used the phrase “Security Protection Asset” and tied the service to CMMC. That's more precise language than much of the MDR market uses, and it tells us the product team is at least speaking the rule's language. Whether your sales conversation, contract, data map, and responsibility matrix reflect that precision is a different question.

What being in scope actually requires

The rule requires the use of the ESP, the relationship, and the services provided to be documented in your SSP and described in the provider's service description and customer responsibility matrix. For a Security Protection Asset, the related asset treatment belongs in the asset inventory, SSP, and network diagram, and the relevant Level 2 requirements are assessed against the capabilities provided.

That means you need, at minimum:

1. the legal and service-provider relationship named correctly;
2. the package and delivered capabilities described;
3. the data flow documented field by field;
4. the responsibility split written down;
5. the service and administrative paths shown in the boundary diagram; and
6. evidence for the relevant requirements the provider claims to support.

This can be manageable. It is not automatically “an afternoon,” and it is not automatically cheap. The cost depends on whether the vendor gives you usable evidence, whether the deployment touches CUI, how many service relationships exist, and how much work your assessor must perform inside the provider relationship.

For the full asset-category and ESP analysis, use our CMMC scoping guide. This page applies that rule to Adlumin specifically. It does not re-teach the entire boundary model.

The distinction almost nobody makes: hosted service vs. on-premises N-central

N-able's CMMC disclaimer says N-central offers a dedicated on-premises edition designed to assist organizations aligning with applicable CMMC controls.

On premises changes the analysis.

That third row is the one that bites. An on-premises remote-management platform with administrative rights over CUI systems is a system you operate inside the boundary. You patch it. You harden it. You produce the evidence. But do not make the opposite mistake and assume “on premises” automatically erases every provider relationship. If N-able or a partner remotely administers, supports, monitors, or receives Security Protection Data from the instance, analyze that service separately.

Not sure whether you need an MDR at all, or something else entirely?

The category you need — a C3PAO, an RPO, an MSSP, a GRC platform, or a CUI enclave — depends on facts a general article cannot resolve for you. Map yours before you request quotes.

→ Use The Defense Compliance Report's Find My CMMC Path tool

Do not submit CUI, drawings, credentials, network diagrams, export-controlled files, or sensitive contract details.

---

What should I settle before I request a single quote?

The right CMMC provider is not the same for every contractor. The category you need depends on your required level, whether you handle FCI or CUI, the assessment designation in your current paperwork, your cloud and IT environment, your data flow, and your contract timeline. A checklist does not bind your assessment path; the solicitation, contract, or flow-down does.

Before a demo, write down five things:

1. The exact contract trigger. Identify the CMMC level and assessment type in the current solicitation, contract, or flow-down — and whether a post-suspension amendment or modification changed it.
2. Your current CUI boundary. Name where CUI is received, processed, stored, transmitted, backed up, and supported.
3. Every audit-relevant source. List endpoints, identity systems, firewalls, switches, VPNs, Linux, cloud services, applications, and operational technology.
4. How each source reaches the MDR. Mark each one API, agent, syslog/non-API collector, or not currently integrated.
5. Who owns the nine families outside the public Adlumin mapping. A blank owner is not a tool gap. It is a program gap.

The first four decide whether the service fits. The fifth decides whether buying it moves the program forward or merely makes one dashboard prettier.

---

Does Adlumin's SOC read my CUI?

Answer capsule: N-able states that, as of September 2025, Adlumin MDR no longer retrieves CUI data from customer environments and that the control is enabled by default for all MDR customers. That is a stronger published default than a vague “we do not need your CUI” statement. It is still a vendor statement with a date attached, and it should be translated into a contract term and a field-level data map rather than taken from a blog post.

We want to be fair here, because this is the part of Adlumin's CMMC posture that holds up best in public documentation.

N-able's position is not merely “please do not send us files.” The company says it implemented technical controls that disable CUI data retrieval by default and made the change effective in September 2025. It also says configurable controls were planned for Q4 2025. We could not verify whether that configurability shipped or who can change the setting now.

The field-level test the marketing sentence does not answer

“CUI retrieval disabled” is not the same claim as “no covered defense information ever leaves the environment.” The DFARS cloud-service trigger turns on whether a cloud provider stores, processes, or transmits covered defense information — not whether an analyst opens a file.

Ask N-able to mark yes, no, or configurable for each field below:

That table is not an accusation that Adlumin collects every field. It is the decision test. You cannot classify the provider relationship accurately from the phrase “no CUI retrieval” alone.

The honest downside — and why the trade may still be right

Here's the part your sales rep will not lead with.

If Adlumin's analysts cannot retrieve file content, their ability to perform content-level damage assessment is limited. Ransomware hits a CAD workstation at 2 a.m. The SOC may see process behavior, authentication events, network calls, endpoint actions, and an encryption pattern. What the SOC may not be able to do under the restriction is open a file and determine what controlled information it contained.

That is a real operational limitation. It is also a predictable consequence of reducing the provider's access to CUI.

Behavioral telemetry is not a consolation prize. Process trees, authentication anomalies, lateral movement, command-line activity, and outbound connections can be critical detection signals. File content is often more important to the later question: what information was affected?

The correct buying question is not “CUI access: yes or no?” It is:

Can this service detect and contain the event without CUI access, and have we separately arranged the content-level damage assessment, reporting support, and evidence preservation the contract may require?

Under DFARS 252.204-7012(b)(2)(ii)(D), the FedRAMP-equivalent and paragraphs (c) through (g) obligations attach when an external cloud service provider stores, processes, or transmits covered defense information. A file-content switch can reduce the chance of that trigger. It does not decide the issue until the complete data flow is established.

Who this genuinely does not work for: if your requirement, insurer, risk tolerance, or incident plan demands full-fidelity forensics inside CUI systems, arrange a provider and process contractually and technically authorized to handle that work. That may involve a constrained CMMC managed enclave, a separate digital-forensics and incident-response retainer, or both. Do not discover the missing capability at hour six of a 72-hour reporting clock.

Three questions to put in writing before you sign:

1. Is the CUI restriction a contractual commitment, a current product behavior, or both?
2. Which exact fields can leave the environment under the quoted deployment, including filenames, paths, command lines, URLs, email metadata, ticket text, and submitted samples?
3. Did the configurable-controls capability roadmapped for Q4 2025 ship — and if so, who can change the setting, what approval is required, and is every change logged?

---

Which Adlumin package do I actually need for CMMC?

Answer capsule: N-able's live MDR page publishes three packages — Managed ITDR, MDR Standard, and MDR Advanced — with data retention of 30, 30, and 90 days. Only MDR Advanced includes the Adlumin VM Collector for non-API ingestion such as syslog. For a defense contractor whose required audit records come from sources that cannot reach the service through a supported agent or API, that one line may decide whether the service can see the required environment at all.

This is where the money is, and it is the section we would read first if we were buying.

N-able publishes the package feature grid on its Adlumin MDR page. We captured it on August 27, 2026. Then we mapped the vendor rows to the NIST SP 800-171 Rev. 2 requirements they may support.

The package gap table

Source: N-able's Adlumin MDR feature grid, captured August 27, 2026. Row labels are the vendor's. The right-hand column is our analysis, not N-able's assessment claim.

Three findings from that grid

One: Managed ITDR is identity-focused, not a complete boundary-wide logging layer on the public package terms. It has no Adlumin endpoint agent, its SIEM is limited to Microsoft data, and its API integrations are listed as Microsoft 365 only. That may be useful for identity risk. It does not, on those published terms, solve audit collection for a mixed CUI boundary.

Two: MDR Standard has a specific, checkable integration limit. It includes the endpoint agent and broader API integrations, but it does not include the VM collector for non-API sources. Ask what generates audit records in your CUI boundary: firewalls, managed switches, VPN concentrators, Linux servers, jump hosts, line-of-business applications, and industrial equipment. For every source, identify the supported path. If the source requires the VM collector, Standard does not include it.

Three: the correct package is a source-by-source decision, not an industry stereotype. If every required source can reach MDR Standard through a supported agent or API, Standard may genuinely be enough. If even one required source needs the non-API collector, price Advanced or document how another system will collect, protect, retain, monitor, and alert on those records. That's not a reason to walk away. It's a reason to price the right architecture the first time instead of discovering the blind spot during a gap assessment.

The package-name conflict you should not ignore

The live product grid names the packages Managed ITDR, MDR Standard, and MDR Advanced. A separate live N-able resource page describes an “Adlumin Packaging Guide” using MDR Base, MDR Complete, and MDR Plus.

That does not prove your quote is wrong. It proves that the package name alone is not enough.

Ask which document governs your quote, and get its version date. Require the quote to list the included agent, API integrations, VM collector, retention, vulnerability scanning, incident-response scope, onboarding, support, and evidence deliverables. A quote written against a package name you cannot reconcile with the live feature grid is a quote you cannot compare.

On pricing: N-able does not publish a current dollar figure on the product page we reviewed. We will not print a number we cannot source. Get a written definition of the billable unit and every minimum, overage, source, retention, onboarding, and add-on charge.

One caution on the compliance reports. All three live packages list reporting and compliance. Reports can be useful evidence. They are not self-proving. An assessor evaluates implementation in your environment through the required assessment methods and objectives. Treat exports as evidence inputs for your SSP and assessment package, not as a substitute for implementation.

Before the demo, do one thing that changes the whole conversation

List every audit-relevant source and mark it agent, API, non-API/syslog, other collector, or not integrated. Then ask N-able to annotate the list against the exact quoted package.

→ Use the 32-point CMMC readiness checklist

That turns “Do we need Advanced?” from a sales opinion into a checkable architecture decision.

---

Which NIST SP 800-171 Rev. 2 requirements can Adlumin actually support?

Answer capsule: N-able's public CMMC article identifies five areas for Adlumin MDR: Audit and Accountability, System and Information Integrity, Incident Response, Access Control, and “Risk Management.” NIST SP 800-171 Rev. 2 calls the closest fifth family Risk Assessment. On the public record, nine of the fourteen families are not mapped by that article. The accurate verb is “supports,” “contributes evidence to,” or “helps implement” — not “covers” in the sense of completing an assessed requirement by itself.

Language matters enormously here, so let's be precise about four different things that get collapsed into one word:

1. A platform capability — the software can do a thing.
2. A configured safeguard — the thing is turned on, tuned, integrated, and running in your environment.
3. A documented implementation — you have written how the requirement is satisfied within your scope and responsibility model.
4. An assessed requirement — the required assessment methods and objectives have been applied to the implementation and evidence.

Vendors sell you the first. Your program has to build the second and third. An assessment evaluates the fourth. The distance between them is the entire job.

The 14-family public-coverage map

Source: N-able's November 2025 CMMC article, its product pages, and our mapping to the NIST SP 800-171 Rev. 2 requirement text. Column two reflects vendor claims. We did not test the product.

Five families publicly claimed. Nine not publicly mapped. That is not a criticism of Adlumin. It is a description of what an MDR service is designed to do. A vendor implying one monitoring contract finishes all 110 requirements should worry you more than this table does.

Two of those nine deserve a flag. 3.13 is where FIPS-validated cryptography appears, and it is a separate architecture and implementation problem; see our CMMC FIPS 140 requirements guide. 3.12 is where the SSP, POA&M, assessment, and ongoing-monitoring work lives. Neither is solved by a SOC watching alerts. Both need an owner before you buy more tooling.

Version control: Rev. 2 controls CMMC Level 2, even though NIST has newer publications

NIST published SP 800-171 Rev. 3 in May 2024. NIST also withdrew the original February 2021 SP 800-172 on May 13, 2026 and superseded it with a later revision.

That does not silently rewrite CMMC.

As of August 27, 2026, 32 CFR Part 170 still ties CMMC Level 2 to NIST SP 800-171 Rev. 2 and uses selected requirements from the February 2021 SP 800-172 for Level 3. Until DoD amends the controlling rule or otherwise lawfully changes the contract baseline, do not let a vendor substitute Rev. 3 as though it were the current CMMC Level 2 control set.

One requirement worth checking that almost nobody asks about

NIST SP 800-171 Rev. 2 requirement 3.3.4 requires alerting in the event of an audit-logging process failure.

Read that again, because it's subtle. It's not merely “collect logs.” It's “know when you stopped collecting logs.”

N-able's November 2025 article says Adlumin provides automated alerting on audit failures. That is a positive vendor claim. What the public material does not demonstrate is the behavior source by source.

So test it in the demo. Ask them to disconnect one endpoint agent, one API source, and one syslog/non-API source. For each, make them show the alert, timestamp, ticket, escalation, restoration record, and evidence export. If the platform does it cleanly, that is a strong signal. If the answer becomes a roadmap conversation, you learned something important for the price of one question.

---

Is 30 or 90 days of log retention enough for CMMC?

Answer capsule: There is no universal CMMC log-retention number. NIST SP 800-171 Rev. 2 requirement 3.3.1 requires audit records to be created and retained to the extent needed to enable monitoring, analysis, investigation, and reporting — a needs-based standard, not a fixed period. Separately, DFARS 252.204-7012(e) requires preserving affected system images and relevant monitoring and packet-capture data for at least 90 days after submitting a cyber-incident report.

We hear “90 days is the CMMC requirement” constantly. It isn't.

What the NIST requirement asks is harder and more useful: retain enough to do the job. The job is monitoring, analysis, investigation, and reporting. Your retention answer is therefore a function of your environment, threat model, investigation timelines, contracts, insurer requirements, and documented process.

The 90-day figure people are half-remembering comes from a different document — DFARS 252.204-7012 — and it is triggered after a reportable incident is reported. That is an evidence-preservation obligation, not a normal logging baseline. Conflating the two creates a specific, expensive mistake: buying 90-day retention and assuming it satisfies both. It may satisfy neither, because incident preservation means identifying and holding the affected images and relevant monitoring data through an operational process, not merely setting a default storage slider.

Three questions that separate a real retention answer from a marketing one:

1. Is the full period searchable in the platform, or does older data move to an archive? Those are not the same thing when you are 40 days into an investigation.
2. Can you export your own records — all relevant fields, cases, and timestamps — on demand and at termination? If your evidence is trapped in a console you are leaving, it is not operationally useful evidence.
3. Who preserves what after an incident, and how? Someone must capture the images and relevant packet or monitoring data. Name the party, tool, trigger, format, chain of custody, and retention location in the incident plan and service description.

The practical read for a small DIB contractor: if your only searchable investigation window is 30 days, eventually you may investigate an event that began earlier than the data you can search. That is not automatically a failed requirement on day one. It is a predictable detection, investigation, and evidence risk that your retention rationale must address.

---

Are N-able's CMMC badges and attestations worth anything?

Answer capsule: They can be useful evidence about N-able's own management system or one product document, but none is your CMMC status. N-able publicly describes ISO/IEC 27001 and SOC-related trust materials and a Coalfire attestation for N-central for CMMC Compliance. We did not verify the full scope of the ISO certificate, the SOC report, or the gated Coalfire letter. None of those items is a CMMC certification of Adlumin, a FedRAMP authorization, or a Level 2 assessment of your environment.

Buyers get badge fatigue, and vendors know it. So let's sort them.

The validation ladder

The Coalfire letter, read carefully

We want to give N-able real credit first: publishing a third-party attestation resource about a responsibility matrix is more useful than publishing a badge with no artifact behind it. It signals that the product team expects customers to ask how responsibilities divide.

Now the precision. N-able's public page says the letter confirms that N-able's CMMC Shared Responsibility Matrix accurately reflects how N-central for CMMC Compliance meets its CMMC Level 2 development responsibilities. That is N-able's description of the letter. It is not a public statement that Adlumin was assessed, that N-central satisfies any requirement in your configured environment, or that deploying either product produces a CMMC status.

Before you cite the letter in your SSP, open the actual document and confirm:

• which Coalfire legal entity signed it;
• the date and validity period;
• the product and version in scope;
• the responsibility matrix version;
• the criteria and evidence reviewed;
• the precise conclusion; and
• every limitation or disclaimer.

Misdescribing a third-party attestation in your SSP is an unforced error. Quote the document you possess, not the summary page you remember.

Shared Responsibility Matrix vs. customer responsibility matrix

N-able calls its artifact a Shared Responsibility Matrix. 32 CFR 170.19(c)(2)(ii) calls for a customer responsibility matrix describing the responsibilities of the organization seeking assessment and the ESP with respect to the services provided.

Those can contain the same substance. The title is not the real issue. The issue is whether the document identifies the exact quoted service, package, deployment, data flow, and responsibility split.

If you buy both Adlumin MDR and N-central, you need the responsibilities for both services documented. That may be two matrices or one combined matrix that unambiguously covers both. Do not accept one generic PDF that leaves you guessing which row applies to which product.

---

What about the N-central bundle — and the August 2026 security incident?

Answer capsule: The vulnerabilities in this section affect N-central, N-able's remote monitoring and management platform — not Adlumin MDR. They matter because N-able markets N-central and Adlumin together for CMMC, the dedicated CMMC edition of N-central is on premises, and N-central can have administrative reach into systems that handle CUI. In July and August 2026, attackers exploited an N-central authentication-bypass path in the wild; N-able released two hotfixes and CISA added the associated vulnerabilities to its Known Exploited Vulnerabilities catalog.

Let's set the tone before the facts, because this section could easily read as a hit piece and it isn't one.

The public record shows a serious event and a response worth reading in full. N-able says Adlumin MDR detected the activity, the company issued guidance, registered CVEs, released Hotfix 1, released a second hotfix when continued monitoring found a related path, published indicators, and warned customers that patching would not remove an actor who was already present. That last part — telling customers the bad news they did not want to hear — matters.

We're including it because you may be deciding whether to deploy a platform with administrative reach into machines where CUI lives. You should know the record and the operating consequence.

The N-central vulnerability ledger

Sources: N-able's August 10, 2026 incident update, N-able's 2025.3.1 release notice, and the CISA KEV catalog. Verified August 27, 2026.

Why this section belongs in a CMMC review

Because of the on-premises detail we flagged earlier.

N-able's CMMC edition of N-central is an on-premises product. On premises means N-able cannot silently make your local patch record appear. You patch it. On your clock. With your evidence trail. In the August 2026 event, N-able deployed mitigations to hosted environments and directed on-premises customers to apply the hotfix. If you operated the CMMC edition, you owned the local action.

Now count the requirements and clause duties that may become relevant when a platform like that is compromised:

• 3.14.1 — flaw remediation. Identify, report, and correct system flaws in a timely manner. Your policy and procedure should define the response timeline and evidence.
• 3.6.1 and 3.6.2 — incident handling and reporting. Preparation, detection, analysis, containment, recovery, tracking, documentation, and reporting to designated officials.
• 3.11.2 — vulnerability scanning. Scan periodically and when new vulnerabilities affecting the system are identified.
• DFARS 252.204-7012(c) — rapid reporting. When the contractor discovers a cyber incident that affects a covered contractor information system, covered defense information residing in it, or operationally critical support as defined by the clause, the contractor must review for evidence of compromise and rapidly report — meaning within 72 hours of discovery.

The paragraph we most want you to read

That DFARS reporting obligation is the contractor's. It is not transferred to your MDR provider merely because the provider found the alert.

Read that with the CUI restriction from earlier in mind, because the two facts collide in an uncomfortable way. If Adlumin cannot retrieve file content, it may be well positioned to identify activity and still be limited in answering which specific covered information was accessed, exfiltrated, or altered. The contractor's review must include identifying compromised computers, servers, specific data, and user accounts.

That is not automatically a defect in the MDR design. It is the predictable consequence of limiting content access. But it means the content-level damage-assessment capability has to come from somewhere else — your team, your MSP, counsel-directed forensics, or a separate incident-response provider — and it has to be arranged before you need it, not at hour six of a 72-hour clock.

Ask the question this week.

What to do if you're running N-central now

Not compliance advice — operational triage based on N-able's published August 2026 guidance:

1. Confirm the installed build number yourself. N-able directed customers to Hotfix 2, build 2026.3.1.10.
2. If either hotfix was applied more than a few days after release, follow N-able's instruction to treat the environment as potentially compromised and conduct a thorough review.
3. Audit user accounts, access privileges, suspicious logins, unexpected account creation, and unexplained password resets.
4. Hunt for the published indicators, including a service named “Cloudflared,” unusual Take Control activity, and N-able's other current indicators.
5. Do not treat a clean IOC scan as proof that the environment was untouched; N-able says the scanner covers known indicators only.
6. Document each action, owner, timestamp, result, and restoration step.
7. If the incident may meet the DFARS reporting trigger, involve the people responsible for the contractual and legal decision immediately.

The gaps this exposes usually are not monitoring gaps

Incident-response planning, forensics readiness, patch evidence, SSP documentation, and reporting ownership are different jobs. An MDR contract does not automatically produce any of them.

→ Compare CMMC provider categories: C3PAO, RPO, MSSP, GRC platform, and CUI enclave

---

Does CMMC Level 2 require a C3PAO during the 2026 Phase II suspension?

Answer capsule: Not as a new procurement designation during the current suspension. On July 13, 2026, the Department announced the immediate suspension of CMMC Phase II, which had been scheduled to begin November 10, 2026. During the suspension, program managers and requiring activities may designate only Level 1 Self or Level 2 Self. They may not designate Level 2 C3PAO or Level 3 DIBCAC. Active solicitations containing those requirements must be amended, and existing contracts containing them must be modified before the next option period or scheduled administrative modification. Phase I self-assessment requirements remain in place.

This is the freshness finding, and it has real money attached.

The original phased schedule put Phase I from November 10, 2025 through November 9, 2026, with Phase II beginning November 10, 2026. The July 2026 suspension stopped that transition and kept the program in the self-assessment phase while the Department reviews CMMC.

We're flagging the N-able pages because two different messages remain live on the same domain:

Captured August 27, 2026. Compare N-able's Level 2 page, CMMC hub, and Phase II article with the Department's implementation memorandum.

We do not think the mismatch proves bad faith. Large websites age unevenly. But the practical consequence is severe: a contractor reading the wrong page could budget for a certification assessment that a requiring activity cannot newly designate during the suspension. That is an expensive decision made on stale implementation language.

What is true right now

Suspended during the current review:

• the November 10, 2026 transition to Phase II;
• new Level 2 C3PAO designations in procurement requests and requirement documents;
• new Level 3 DIBCAC designations under the CMMC phased implementation;
• the related waiver process described in the implementation memo.

Still in place where the clauses and contract facts apply:

• Phase I Level 1 Self and Level 2 Self requirements;
• DFARS 252.204-7012 safeguarding and cyber-incident obligations;
• DFARS 252.204-7019 and 252.204-7020 NIST SP 800-171 DoD assessment and SPRS requirements;
• DFARS 252.204-7021 CMMC record, UID, subcontract, and affirmation duties where the clause and current requirement apply;
• implementation of the controlling NIST SP 800-171 Rev. 2 requirements; and
• government-led assessments conducted under applicable authorities outside a newly designated CMMC Level 3 procurement requirement.

One distinction matters: a CMMC Level 3 DIBCAC assessment designation is not the same thing as a Medium or High NIST SP 800-171 DoD Assessment under DFARS 252.204-7020. Do not use the suspension to assume every government assessment stopped.

The buying implication is the whole point of this section. If a vendor — any vendor, in any category — tells you to sign this quarter because of a certification deadline, ask them to name the deadline, identify the current written requirement, and cite the issuing authority. Urgency built on the suspended November 10, 2026 transition is not urgency. It's a close.

Because the Department's review can produce new guidance, reconfirm the phase status against the DoD CIO CMMC page and your written solicitation, contract, amendment, modification, or flow-down before making an assessment purchase.

For the full path decision, see our Level 2 self-assessment vs. C3PAO guide. If you are still settling the underlying requirement or budget, use our CMMC levels guide and CMMC Level 2 cost guide.

---

What should I demand from N-able before an assessment or self-assessment?

Answer capsule: A badge is not your evidence package. For an ESP relationship, the rule expects the provider relationship in the SSP and the service described through a service description and customer responsibility matrix. Seven documents plus four facts will expose most of the expensive unknowns before you sign.

Here's the reciprocity part of this page: take this list, put your vendor's name on it, and send it. It works on any MDR vendor, not just this one.

The seven documents

1. Adlumin MDR service description — naming the exact package, SKU, capabilities, support model, deployment, data fields, and response actions in your quote.
2. Adlumin MDR customer or shared responsibility matrix — with written confirmation that it describes the OSA/ESP split required by 32 CFR 170.19(c)(2)(ii) for the quoted service.
3. N-central responsibility matrix and service description — covering the separate product and support relationship if you buy the pair; one combined document is acceptable only if it unambiguously addresses both.
4. The current ISO/IEC 27001 certificate and scope statement — legal entities, locations, services, certificate number, issue date, and expiry, plus written confirmation of whether Adlumin MDR and the SOC operation are inside scope.
5. The relevant SOC report — under NDA if necessary, including scope, period, exceptions, and complementary user-entity controls.
6. The full Coalfire attestation letter — not only N-able's summary page; require the signer, legal entity, date, product/version, matrix version, criteria, conclusion, and limitations.
7. A written responsibility position for DFARS 252.204-7012 paragraphs (c) through (g) — incident review and reporting support, malicious-software submission, media and data preservation, forensic access, and damage-assessment cooperation. “Reasonable cooperation” is not the same thing as a usable operating procedure.

The four facts that are not established by the public pages

• Data location — where every relevant field is stored, processed, backed up, and supported.
• Retention and export — searchable period versus archive, export fields and format, termination rights, and deletion schedule.
• Subprocessors — which entities touch the data, in which countries, and for which function.
• Analyst and support access — who can view or administer the service, under what controls, and whether any contractual personnel restrictions apply.

Twelve questions for the demo

Bring these. Ask them in this order. The answers are worth more than the dashboard tour.

1. What exact package and SKU are you quoting, and what is the version date of the package document that governs the quote?
2. Your live MDR page and packaging guide use different package names. Which names map to which current entitlements?
3. Which of my audit-relevant sources use the endpoint agent, an API, or the non-API VM collector, and is every required path included in the quote?
4. Disconnect one agent source, one API source, and one non-API source. Show me the failure alert, timestamp, ticket, escalation, restoration, and export.
5. Show me the live CMMC-specific report. What is its last-updated date, which NIST revision does it map to, and which fields are vendor-populated versus customer-entered?
6. Is the CUI retrieval restriction contractual, technical, or both? Who can change it, what approval is required, and is the change logged?
7. Which exact fields leave my environment — including file names, paths, command lines, URLs, email metadata, user and group names, ticket text, and submitted samples?
8. Where is that data stored, processed, backed up, and supported, and which subprocessors touch it?
9. Which response actions do your analysts take automatically, which require approval, and which are unavailable under the CUI restriction?
10. Is digital forensics and incident response included in this quote, limited to telemetry, or sold as an add-on?
11. If a DFARS-reportable incident occurs, who gathers the facts, who identifies the affected data, who preserves images and relevant monitoring data for 90 days, and who submits the report?
12. If I terminate, what logs, cases, reports, mappings, configurations, tickets, and responsibility documents can I export, in what format, within what period, and at what cost?

Ready to compare a scoped quote instead of a generic demo?

Send only non-sensitive buying facts: required level, current assessment designation, high-level boundary, source count, environment, and timeline. Do not send CUI, drawings, contract numbers, credentials, network diagrams, incident evidence, or export-controlled content.

→ Request matched CMMC provider quotes

Provider matching may generate referral or lead-routing compensation. Any commercial relationship is disclosed at the point of recommendation and does not change this editorial analysis.

---

Who should shortlist Adlumin — and who should walk away?

Answer capsule: Adlumin is a reasonable shortlist for a small or mid-sized DIB contractor or MSP that needs 24/7 monitoring, log correlation, and response support — and already has a separate owner for scoping, documentation, incident decisions, and the requirement families the MDR does not publicly map. It is the wrong purchase for a contractor that has not yet defined its CUI boundary, confirmed its current assessment designation, or listed the sources the service must monitor.

We'd rather lose you here than watch you spend wrong.

That last distinction is not a technicality. 32 CFR 170.8 requires the Cyber AB's conflict-of-interest and professional-conduct policies to prohibit a CMMC ecosystem member from participating in a Level 2 certification assessment when that member previously served as a consultant to prepare the organization for any CMMC assessment within the prior three years.

The rule does not say every readiness and assessment function in every circumstance must always be purchased from entirely unrelated companies. Our editorial recommendation is still the clean line: separate the readiness work from assessor selection, disclose every relationship, and make the C3PAO confirm independence in writing before assessment. That protects the assessment and keeps a sales relationship from becoming an avoidable conflict.

---

Frequently asked questions about Adlumin and CMMC

Is Adlumin CMMC compliant?

No — and N-able says so on its own CMMC page. A commercial product does not receive your contractor information system's CMMC status. A product can support implementation and generate evidence. It cannot carry the assessed status for your scope.

Can Adlumin get my company to CMMC Level 2 by itself?

No. Level 2 is tied to 110 requirements across 14 families in your environment, the associated assessment objectives and evidence, your System Security Plan, gap remediation and permissible POA&M mechanics, the required SPRS records, annual affirmation, and the assessment path in your current paperwork. N-able's public Adlumin mapping points to five areas, not all fourteen.

Does Adlumin access my CUI?

N-able states that CUI retrieval is disabled by default for all MDR customers, effective September 2025. Confirm the exact field-level data flow for the quoted deployment and put the restriction, change authority, audit trail, and incident exceptions in the service description and contract.

If Adlumin never opens CUI files, is it out of my assessment scope?

No. If the service processes Security Protection Data without CUI, 32 CFR 170.19 puts the services in scope and assesses them as Security Protection Assets. If it processes CUI, the CSP/non-CSP branch of the ESP rule applies. “No file retrieval” reduces one possible data path; it does not erase the service from scope.

Is Adlumin FedRAMP authorized?

We did not verify a current authorization or package ID. Do not rely on “FedRAMP ready,” “equivalent,” or inherited language. Ask for the exact Marketplace listing and verify that the authorized service and boundary match what you are buying. FedRAMP relevance turns on whether an external cloud provider stores, processes, or transmits covered defense information under DFARS 252.204-7012.

Is Adlumin a C3PAO or an RPO?

Its documented role is MDR/XDR security operations. Do not treat it as a C3PAO, RPO, or RP without an exact, current Cyber AB Marketplace listing for the legal entity and role. Product expertise and partner relationships are not marketplace authorization.

Which Adlumin package do I need for CMMC Level 2?

It depends on what generates the audit records your boundary requires and how each source connects. On the live package grid, only MDR Advanced includes the VM collector for non-API ingestion such as syslog. Standard may be enough if every required source can reach the service through its included agent or supported API. Managed ITDR is identity-focused and lacks the Adlumin endpoint agent on the public grid.

Why do N-able's package names not match across its pages?

The live MDR page names Managed ITDR, MDR Standard, and MDR Advanced. A separate live packaging resource names MDR Base, MDR Complete, and MDR Plus. Require N-able to map the quoted SKU to the current entitlements and identify the governing document version before you compare prices.

How much does Adlumin cost?

N-able does not publish a current dollar price on the product page we reviewed. Get a quote that separately identifies the package, SKU, billable unit, source count, collector, retention, vulnerability scanning, response scope, onboarding, support, contract term, overages, and evidence deliverables. Otherwise you cannot compare it to anything.

Is 90 days of log retention a CMMC requirement?

No. NIST SP 800-171 Rev. 2 requirement 3.3.1 uses a needs-based retention standard. The separate 90-day figure in DFARS 252.204-7012 applies to preserving affected system images and relevant monitoring and packet-capture data after a cyber-incident report. Different obligation, different trigger.

Does Adlumin write my SSP or POA&M?

Not based on the public service material we reviewed. Reports, service descriptions, and responsibility matrices can supply technical facts that go into those artifacts. The SSP, POA&M governance, assessment preparation, and ongoing-monitoring strategy need a clearly named owner.

Who files the 72-hour incident report if the SOC finds something?

The DFARS clause places the rapid-reporting duty on the contractor when its trigger is met. The MDR provider may supply investigative detail and support, but the contractor must have the reporting decision, submission, preservation, and cooperation process assigned in writing before an incident.

Did the August 2026 vulnerabilities affect Adlumin?

The CVEs documented here affect N-central, not Adlumin MDR. The incident is relevant because N-able markets the products together, Adlumin MDR detected the exploitation according to N-able, and the on-premises CMMC edition of N-central is an asset the contractor patches and evidences.

Does N-able's Coalfire letter mean the product passed a CMMC assessment?

No. N-able describes the letter as an attestation that its Shared Responsibility Matrix accurately reflects how N-central for CMMC Compliance meets stated Level 2 development responsibilities. That is not a C3PAO assessment, not a FedRAMP authorization, not evidence that Adlumin is covered, and not a guarantee about your outcome.

Does CMMC Level 2 use NIST SP 800-171 Rev. 3 now?

No. NIST published Rev. 3, but 32 CFR Part 170 still ties CMMC Level 2 to NIST SP 800-171 Rev. 2 as of August 27, 2026. Do not let a current NIST publication date silently replace the controlling CMMC version.

Does NIST SP 800-172 apply to Adlumin or CMMC Level 2?

Not as the Level 2 baseline. The CMMC rule uses selected enhanced requirements from the February 2021 SP 800-172 for Level 3. NIST later withdrew and superseded that publication, but the rule's incorporated CMMC baseline does not change until DoD changes it through the controlling mechanism.

N-able's site says I need a C3PAO. Do I?

Check the current written requirement. During the Phase II suspension, requiring activities may designate only Level 1 Self or Level 2 Self, and active C3PAO or Level 3 requirements must be amended or modified under the July 2026 implementation memo. A C3PAO remains the certification-assessment provider when a valid Level 2 C3PAO path applies, but do not buy one from a stale webpage or suspended deadline.

---

How did we research this, and how can you correct it?

We built this from primary sources first: 32 CFR Part 170 for program and scoping rules; NIST SP 800-171 Rev. 2 for the Level 2 requirement text; DFARS 252.204-7012, 252.204-7019, 252.204-7020, and 252.204-7021 for contractual and SPRS duties; the DoD CIO CMMC page for the Phase II suspension; the CISA KEV catalog for the vulnerability record; and N-able's SEC filing for the corporate facts.

Then we read N-able's current product pages, package tables, CMMC solution pages, incident updates, blog posts, and attestation summary — and recorded verification dates so the freshness findings are checkable rather than asserted.

Community discussion can help identify questions buyers care about, but forum posts are not evidence of regulatory requirements or current product behavior. No regulatory conclusion on this page rests on a forum post.

Where N-able makes a claim we could not independently test, we labeled it as a vendor statement and gave you a way to verify it. Where we could not establish a fact, we did not fill the gap with a confident guess.

Read more about our methodology, editorial standards, and editorial and advertising policy.

This is educational research, not legal, contractual, procurement, cybersecurity, or compliance advice. Confirm your scope, required level, current assessment designation, clause set, and reporting obligations with a CMMC Registered Practitioner, Registered Provider Organization, qualified federal-contracts attorney, and the responsible contracting parties. Your current written requirement and actual FCI/CUI handling control — not a checklist, not this article, and not a vendor product page.

The Defense Compliance Report is an independent trade publication on CMMC and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, CISA, SPRS, or any U.S. government agency.

Found something outdated? Send us the primary source or current vendor document. We check material corrections against the issuing authority and update the verification date when we make a substantive change. See our corrections policy.

---

Need help deciding what type of CMMC provider you need?

Tell us your required level, current assessment designation, high-level scope, environment, and timeline, and we'll route you to source-checked provider categories and options.

→ Find My CMMC Path

Do not submit CUI, drawings, credentials, network diagrams, incident evidence, export-controlled content, contract numbers, or sensitive contract details. The CMMC Path Framework routes to a provider category — it is not an assessment, legal opinion, binding scope determination, provider ranking, or guarantee of any compliance outcome. Provider matching may generate referral or lead-routing compensation, disclosed at the point of recommendation.

---

The Defense Compliance Report — the independent CMMC decision layer for defense contractors. Choose the right CMMC path before you hire.