CMMC Level 2 SaaS Consumer Evidence for MSP Platforms

United States defense contractors, primes, and MSPs serving the defense industrial base face CMMC Level 2 assessments that evaluate access control, audit accountability, and system integrity across enclave boundaries.

When an MSP introduces Trustholm as a SaaS subprocess for signed PowerShell orchestration, assessors ask how that vendor contributes to-and does not substitute for-the customer's certification program. Trustholm is not CMMC Level 2 certified, does not hold C3PAO assessment outcomes for the product, and does not claim certified enclave status.

We supply consumer-side enabler evidence for Access Control (AC), Audit and Accountability (AU), and System and Information Integrity (SI) themes while your organization owns SSP content, POA&M entries, personnel screening, and enclave architecture.

CMMC is an organizational outcome-not a product sticker

CMMC Level 2 practices apply to the assessed environment-networks, endpoints, people, and subprocessors as scoped by the prime or agency. SaaS vendors cannot "be CMMC Level 2" in the same way a manufacturing line cannot inherit a prime's certification by shipping a component.

Trustholm helps defense-facing MSPs document vendor inputs honestly: RBAC, MFA for portal administrators, security audit export, signing policy enforcement, and tenant isolation architecture.

Avoid procurement language such as "CMMC compliant product" or "Level 2 certified platform." Use phrasing such as: "Trustholm enables AC, AU, and SI themes via portal IAM, audit export, and signing enforcement; CMMC assessment remains the customer enclave outcome."

This resource complements /compliance/us/cmmc-readiness with MSP buyer narrative for questionnaires, POA&M drafting, and customer SSP attachments.

Access Control (AC) enablers

Portal RBAC: Users and roles UI gates script publish, approve, and execute permissions within tenant scope. Map product roles to your IdP groups and document periodic access reviews on the customer side.

MFA for administrators: Security Center surfaces MFA status for privileged portal access. This supports AC practices for management-plane authentication-not every end-user laptop in the estate.

Tenant binding: JWT TenantId must match resolved tenant for portal users. Reduces cross-tenant access via header manipulation-a reproducible trial test for assessor walkthroughs.

Agent credentials: Agents use tenant code headers and per-agent polling credential hashes-distinct from shared portal passwords on endpoints. Document agent runtime tenant binding after reinstall in your evidence pack.

Audit and Accountability (AU) enablers

Security audit export records who published, approved, and executed scripts, with signing policy context. GET /api/audit/export supports JSON/CSV with category and datetime filters within documented row caps. Pair export with your log retention, review procedures, and SOC operations-Trustholm does not operate your security operations center.

Gap honesty: Application audit rows are append-only in normal flows, but database operators could mutate tables. Per-tenant integrity hash-chain verification is shipped; product WORM storage remains backlog. Document compensating controls: restricted DBA access, backup review, and export cadence to immutable GRC storage.

System and Communications Protection (SC) and Integrity (SI)

TLS: Portal and API traffic use TLS in standard deployments. Network segmentation between your MSP operations center and customer environments remains your architecture decision.

Signing enforcement: Tenant signing policy blocks unsigned execution when required-failure is explicit at queue dispatch. This addresses script integrity for remote PowerShell, not full endpoint application allowlisting.

Platform script catalog: Published platform scripts with reserved tags support centralized built-in operations-reducing ad hoc unsigned snippets in technician workflows.

Consumer vs provider responsibility split

Provider (Trustholm): Application features, schema-per-tenant isolation, audit APIs, subprocessors transparency, honest Shipped/Gap tables on trust hub, enterprise contract terms for support and notification.

Consumer (MSP or prime): SSP authorship, incident response execution, endpoint baseline and patch cadence, vulnerability remediation, physical security, personnel screening, CUI enclave design, and CMMC assessment scope definition across the system boundary.

Government-facing MSPs attach Trustholm vendor evidence to customer SSP packages. The prime or agency assessor evaluates the customer system-Trustholm is one vendor among many.

POA&M and gap disclosure for defense supply chain

When customers request POA&M templates, supply limitations blocks alongside compensating controls for backlog items:

| Topic | Status | |-------|--------| | CMMC Level 2 product certification | Not claimed | | Native SIEM connector | Backlog | | WORM / hash-chain audit immutability | Backlog | | CUI enclave isolation design | Customer architecture |

Assessors appreciate vendors who name gaps early. Silent omission creates findings during C3PAO review.

Dedicated database and enclave conversations

Enterprise DedicatedDatabase profiles via connection secret reference support separate database instances for customers requiring stronger separation. Application-layer schema-per-tenant isolation is the default.

Enclave design-including whether CUI processing occurs on endpoints administered via Trustholm versus within the SaaS boundary-is customer architecture. Do not imply product-level enclave certification.

Trial evidence pack for CMMC-oriented evaluations

Within the first evaluation week: (1) demonstrate signed execution blocked when policy requires signatures; (2) export audit JSON for script publish/approve/run sequence; (3) capture IAM and MFA screenshots; (4) run cross-tenant JWT mismatch test; (5) attach subprocessors list and gap table. Store artifacts in version-controlled diligence folder-not ad hoc email threads.

Workshop agenda for defense-facing MSPs

Ninety-minute session with security engineering and account teams: map CMMC AC/AU/SI practices to Trustholm rows; mark customer-operated practices (patch, physical, personnel); draft customer SSP vendor appendix language; assign POA&M owner for backlog gaps; schedule quarterly reproduction of audit export. Revisit when trust hub evidence rows change.

Trust hub cross-reference

See /compliance/us/cmmc-readiness for practice mapping and /trust/security for Shipped/Gap tables. CMMC Level 2 certification is not claimed for the product.

Appendix: evidence reproduction steps

Assign a reviewer to open trial tenant, navigate documented UI paths, and capture screenshots with timestamps. Export audit JSON for same session.

Store in immutable GRC folder. Compare results to this article quarterly.

When Shipped/Gap rows change in trust hub, re-run reproduction within ten business days. Attach limitations memo for WORM audit and Sentinel connector backlog.

Include DB operator access policy from hosting provider. Pair technical evidence with customer governance documents-policies, pentest summaries, IR runbooks.

Never substitute marketing copy for reproduced checks in front of assessors. Treat this appendix as a living runbook section owned by security engineering, not a one-time audit artifact.

Schedule annual refresh aligned with trust hub version stamps and major product releases. Link each reproduction run to a change ticket for traceability.

Distribute updated article PDFs to customer-facing teams when dateModified changes. Archive prior versions for twelve months to support assessor lookback questions.

When citing this article externally, include dateModified and pillar metadata in footnotes so readers know content freshness. Internal enablement should link pillar tags to trust hub sections for consistent customer messaging.

Add article slug to internal wiki index for sales engineering quick lookup during live questionnaire calls.