Self-hosted team chat for CMMC and CUI

Self-hosted team chat for CMMC and CUI: what the framework asks of your chat platform

If chat messages or attached files contain Controlled Unclassified Information (CUI), the chat platform sits inside your CMMC assessment boundary, and three Level 2 practices decide whether a self-hosted Mattermost or Matrix enclave can carry that traffic: AC.L2-3.1.3 (control the flow of CUI), SC.L2-3.13.8 (cryptographic protection of CUI in transit) and AU.L2-3.3.1 (create and retain audit records). SC.L2-3.13.8 is the one that cannot be deferred. It is a 3-point requirement, so under the CMMC scoring method a NOT MET result is subtracted from the score of 110 and cannot be carried on a POA&M, which makes it a must-meet item for Conditional or Final Level 2 status. AC.L2-3.1.3 is worth 1 point and may be placed on a POA&M if the score stays at or above 88, but a POA&M does not help if CUI can leave the enclave through an unmanaged channel. Treat these three as design inputs before you choose a platform, not as paperwork to add later.

Current program status matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Level 2 requirements are identical to NIST SP 800-171 Rev. 2, even though NIST withdrew that revision in favor of Rev. 3, because the CMMC rule still incorporates Rev. 2. Confirm the current phase and the contract clauses that apply to your work with your contracting officer and the DoW CIO's CMMC pages before you scope the enclave, since the schedule has been changing.

The practical first step is to map where CUI can appear in your chat: channel membership, guest accounts, file uploads, mobile clients, push notifications and any bridge or integration that copies messages out. Decide which of these count as part of the boundary, then check each platform's edition against the three practices. Confirm in writing with your vendor or partner whether SSO, audit logging and the encryption settings you need are in the edition you buy, because these features sit on paid plans for both Mattermost and Rocket.Chat. Keep the evidence in its final form, since an assessor scores a requirement as MET only when all applicable assessment objectives are satisfied with final evidence, not drafts.

Which CMMC Level 2 practices govern CUI in chat, and how to configure them

This table maps the three CMMC Level 2 practices that most directly shape a chat enclave (AC.L2-3.1.3, SC.L2-3.13.8 and AU.L2-3.3.1) to what the platform must do and how to configure it. Read each row as a requirement, the assessment objectives an assessor works from, and the configuration areas to document and test before go-live.

Practice	What the chat platform must do	Configuration to document and test
AC.L2-3.1.3 (CUI flow control)	Define which channels, teams and files may hold CUI, which users and external domains may receive it, and enforce those flow authorizations in the platform.	Restrict CUI channels to approved members, disable or limit guest accounts in those channels, and turn off or allow-list federation domains. Record the approved flow rules in the system security plan.
AC.L2-3.1.3 assessment objectives	NIST SP 800-171A asks the assessor to see a written flow policy, the methods and enforcement points for CUI, the designated sources and destinations, and evidence that approved authorizations are enforced.	Keep a current map of CUI channels, their members and allowed external destinations, with a change record for each approval. Test that a user outside the approved group cannot post or view CUI content.
SC.L2-3.13.8 (CUI in transit)	Apply cryptographic protection to CUI on every transmission path, or use alternative physical safeguards that the organization has defined and can show.	Enforce TLS on browser, desktop and mobile client connections, server-to-server links, database connections and file storage connections. Disable plaintext listeners and document the cipher settings the platform uses.
SC.L2-3.13.8 assessment objectives	The assessor expects the cryptographic mechanisms or alternative safeguards to be identified in writing and shown to be implemented during transmission, not only planned.	Capture configuration evidence from the server, reverse proxy and client settings. For federation or bridges, confirm the remote path is encrypted and that the remote operator's controls are in the scope documentation.
AU.L2-3.3.1 (audit records)	Create audit records for security-relevant user and admin actions, including logins, permission changes, channel and file events, and retain them for the defined period.	Enable the audit and admin activity logs the edition supports, then forward them to a central log store. Confirm which events are captured and whether they cover file uploads and downloads.
AU.L2-3.3.1 assessment objectives	NIST SP 800-171A asks for a defined list of event types, records containing the required content (such as who, what, when and where), and a stated retention period that is met.	Write the event catalog and retention rule in the audit plan. Run a sample test that performs a known action, then shows the matching record with the required fields in the exported log.
Identity and access (supports all three)	Authenticate users through the organization's identity provider and require multi-factor authentication for CUI access. Remove access quickly when people leave the program.	Configure SSO through SAML or OIDC, sync users from the directory, and enforce MFA at the identity provider. Confirm which SSO and directory features each edition includes before purchase.
Edition and support status (scope)	Choose an edition and version that supports the controls above and is still receiving security fixes, since unsupported releases can lose fixes and client compatibility.	Check the platform's edition matrix for SSO, audit export, federation controls and air-gapped use. Confirm the current support window and plan a patch cycle the enclave can meet.

How CUI moves through chat channels, files and guests

CUI in a chat workflow rarely stays in the message body. It also sits in file attachments, pinned messages, search indexes, mobile app caches, push notification previews and any room that is bridged to another network. Each of these is a separate path for CUI to leave its intended audience, and AC.L2-3.1.3 expects the organization to control all of them under approved authorizations. Before any configuration work starts, list every surface where chat content is stored or relayed, and mark which of those surfaces will hold CUI. That inventory becomes the basis for the flow authorization record.

The flow authorization decision must be written down before anyone enforces it. NIST SP 800-171A asks an assessor to see defined information flow control policies, the designated sources and destinations of CUI, and the authorizations that permit each flow, followed by evidence that those authorizations are enforced. For chat, the written record should state who may see which CUI, in which channels, from which devices and through which guest or external accounts. A separate enclave for CUI reduces the number of flows to authorize, because general-purpose workspaces, partner rooms and mobile clients outside the enclave are excluded by design rather than by a long list of exceptions. Confirm with your assessor how they will test the boundary of that enclave before you build it.

The choice of platform changes which controls are native and which must be enforced by process or network design. Mattermost and Rocket.Chat both offer role-based channel permissions, directory-based access and audit features on their paid tiers, but you should verify in your own test environment whether each control covers files, search and notifications the way your flow record requires. Matrix federation can relay room content to other homeservers, so federation is either disabled for the enclave or restricted to a documented allow-list, and that restriction usually has to be enforced at the network layer as well. Mobile caching and push previews are often outside the server's control, so plan device management and notification content settings as part of the authorization, not as an afterthought.

Which self-hosted chat platforms fit a CUI enclave

Three platform families can host chat inside a CUI boundary, but each one reaches the CMMC Level 2 practices through a different edition, license model and set of paid features. The cards below set out where each fits, which tier supplies the CUI-relevant controls, and what to confirm with the vendor before the enclave design is fixed.

Mattermost in Enterprise tiers

Mattermost compiled binaries are MIT licensed, and its source is available under AGPL-3.0, so the open-source route is workable for a self-hosted enclave. The FIPS 140-3 compliance and air-gapped deployment sit in the Enterprise and Enterprise Advanced plans, so the enclave design depends on which tier you buy. High availability also requires shared file storage on S3, an S3-compatible service or NAS mounted on every node, which must sit inside the CUI boundary. Confirm the FIPS validation scope for your exact build and version with Mattermost.

Rocket.Chat on paid Government plans

Rocket.Chat code is MIT licensed except the ee directories, which fall under a separate enterprise license, so any CUI deployment touches a commercial component. The Starter plan includes LDAP, SSO, MFA and end-to-end encryption, but air-gapped deployment and the tamper-evident audit trails for messages, files and sessions are paid-plan capabilities. Its 8.x line requires MongoDB 8.0 or later as a replica set, and that database must also sit in the enclave. Standard releases get six months of support, so plan a recurring upgrade cycle that your change control can absorb.

Matrix via Synapse with federation locked down

Synapse is AGPL-3.0 licensed, which gives a fully open-source homeserver with no paid tier required for the core server. The CUI risk is federation: by default a homeserver can exchange messages with other servers, so federation must be disabled or limited to an explicit allow-list of domains covered by your agreements. Matrix also changes the audit story, because audit records, retention and export depend on how your deployment and clients are configured. Confirm with Element or your partner which audit and retention features apply to your Synapse version.

Confirm FIPS and cryptography scope

A CUI enclave must implement cryptographic mechanisms that prevent unauthorized disclosure of CUI during transmission, so the choice of platform starts with the TLS and encryption stack it actually uses. Ask each vendor which cryptographic modules are validated, which algorithms are enabled by default, and whether the mobile and desktop clients use the same protections. Keep the answers in writing, because the assessor will look for evidence of the configuration in final form.

Edition and support window risk

Every platform in this comparison changes its supported version set on a regular cadence, so the chosen edition must match a version you can keep patched. A CUI enclave that falls off vendor support cannot easily meet the system and information integrity expectations in its assessment. Ask each vendor for its current support calendar, the process for offline upgrades inside the enclave, and whether paid support covers the version you run.

Licensing and commercial components

Read the license for each component you deploy, not only the core product. Mattermost ships MIT binaries alongside AGPL-3.0 source with a commercial option, Rocket.Chat depends on an enterprise license for its ee code, and Synapse is AGPL-3.0 throughout. Define which add-ons, clients, bridges and plugins sit inside the enclave, and confirm that each one is covered by the license terms you accept for the CUI environment.

How to build the enclave in order: boundary, identity, encryption, logging

This sequence turns a chat platform into an enclave whose CUI boundary, access paths, encryption and audit evidence can be shown to an assessor. Each step closes with a artifact that the next step depends on.

Define the assessment boundary and CUI flows
Before any server is provisioned, the sponsor and the compliance lead map where CUI enters the chat, which channels, direct messages, file uploads and integrations can carry it, and which users, devices and external parties may receive it. The output is a boundary diagram and a data flow register that names every source and destination of CUI. Check it by walking one real file from upload to download and confirming each hop appears in the register. Confirm the scoping position with your C3PAO or advisor before buying licenses.
Deploy the platform in an isolated enclave
The platform team deploys Mattermost or Rocket.Chat, along with its database and file storage, inside a dedicated network segment that only the approved user paths can reach. Confirm with the vendor which edition supports the deployment model you need, since air-gapped and high availability options sit on paid plans. The check is a network test showing that hosts outside the boundary cannot reach the database, file store or admin interfaces directly. Record the configuration baseline in version control so the state can be reproduced for assessors.
Integrate SSO and multi-factor authentication
Identity administrators connect the chat to the corporate directory through SAML or OIDC and sync group membership so that access follows the same joiner and leaver process as other enclave systems. MFA is enforced at the identity provider, and local password logins are restricted to a documented break-glass account. The output is a test matrix showing that a disabled account, a user outside the authorized group and a session without MFA are all refused. Confirm in the paid plan documentation which SSO and group mapping features your edition includes.
Enforce TLS on every client and node link
The network team terminates TLS for browsers, desktop and mobile clients, and the load balancer, and encrypts the links between application nodes, the database, the search service and the file store where the product supports it. Certificates come from an internal authority that the approved devices trust, and weak protocol versions are disabled at the edge. The check is a scan of every listening endpoint in the enclave confirming that only approved protocol versions and cipher suites are offered. Keep the scan report with the boundary diagram as evidence for the encryption requirement.
Disable federation and restrict guest access
The administrator turns off federation with external servers and disables open guest self-registration unless a documented external collaboration case exists. Any remaining external accounts are invited individually, placed in a restricted group and limited to channels approved in the data flow register. Where federation is later needed, it is allow-listed by domain and reviewed as a change to the boundary. The output is a configuration export and a test in which an outside account cannot join a CUI channel. Ask the vendor how each setting is stored so the export can be captured in your evidence set.
Configure retention, legal hold and audit export
The compliance lead sets message and file retention periods, defines which event types are logged for user and administrator actions, and configures a secure export of audit records to a log store that the enclave operators cannot silently edit. The record content should cover who acted, what they did, when, and from where, and the retention period must match the organization's own contractual and regulatory requirement. The check is an exported sample of audit records for a test user, reviewed against the logging objectives in your assessment plan. Confirm with the vendor which audit and export features require a paid edition.
Run a documented evidence test before go-live
Before the enclave is declared live, the compliance lead and an independent tester run a scripted evidence run that exercises each requirement: boundary tests, access refusal cases, encryption scans, guest and federation checks, and audit record generation. Each result is stored with the date, the tester, the configuration version and a pointer to the final-form artifact. Gaps are logged as a plan of action or fixed before scoring, since a requirement counts as met only when its evidence is final. This run becomes the baseline for the assessment and for every later change.
Keep the release cadence and patch window current
After go-live, the platform team treats upgrades as an ongoing control. Mattermost publishes a new server version each month and the Extended Support Release line gives a longer window, while Rocket.Chat standard releases have a six-month support life and LTS releases have twelve months. Each upgrade goes through a staging enclave, reruns the evidence tests and updates the configuration baseline. Confirm your chosen release line and its end-of-support date in writing with the vendor, and schedule the next upgrade before the current one expires.

What assessors ask to see for chat and CUI, and which component produces it

This table lists the artifacts an assessor typically asks for when chat carries CUI, and the component that produces each one. Read it as a checklist for the enclave design: if a component cannot produce its artifact, the matching practice is harder to show. A requirement is MET only when every applicable assessment objective has evidence in final form, so a complete folder of drafts does not count.

Evidence artifact	Producing component	What the assessor checks	Where it usually falls short
CUI flow authorization policy	Document control system (approved policy and approval records)	Defined information flow rules, sources and destinations of CUI, and the approvals behind them (AC.L2-3.1.3)	Policy exists but does not name chat channels, guests or file types that may carry CUI
Channel and permission configuration export	Chat admin console (team, channel and role settings, guest and external access)	Which channels may hold CUI, who can join, and that the configuration matches the approved policy	Export taken from a test instance, or private channels and guest accounts left out
TLS configuration and certificate inventory	Reverse proxy and chat server configuration, plus certificate management records	Cryptographic protection for CUI in transit between clients, proxy and nodes (SC.L2-3.13.8)	Internal hops between application nodes and the database run without encryption and are not documented
SSO and MFA settings	Identity provider and chat SSO configuration (SAML, OIDC or LDAP sync)	Users authenticate through the approved identity source with multi-factor controls, and deprovisioning follows the directory	Local password accounts remain enabled for administrators or service users
Audit event type list with sample records	Chat audit log and SIEM (event definitions and exported records)	Defined event types, the content each record holds, and records that show who did what and when (AU.L2-3.3.1)	Sample records lack user, time or channel fields, or logs stay on the chat host only
Log retention settings	SIEM or log store (retention configuration and storage policy)	Retention period set to meet the organization's own requirement and documented in the policy	Retention configured in one place but not in the SIEM, so older events are gone
Final-form procedures and runbooks	Document control system (approved, dated versions)	Procedures for account setup, channel creation, CUI handling and log review are final and approved, not drafts	Runbooks changed after the last review with no version history or approval date

How the scoring rules change the chat decision

AC.L2-3.1.3 asks you to control the flow of CUI in line with approved authorizations. In chat, that means defining which channels, direct messages, guest accounts, federated servers and file attachments may carry CUI, then enforcing those rules in the platform and backing them with a written policy. Under 32 CFR 170.24 it is worth 1 point, which makes it eligible for a POA&M under the Conditional Level 2 path. The NIST SP 800-171A assessment objectives expect you to define the flow control policy, the enforcement mechanisms, the designated sources and destinations of CUI, and the flow authorizations, then show that those authorizations are enforced.

Source and destination map: list the channels, teams and users designated for CUI, and the ones excluded from it.
Federation boundary: if you run Matrix federation or allow connections to external servers, document each permitted domain and block the rest.
Guest and external access: define who may join a CUI channel as a guest and who approves that access.
File and export controls: decide whether attachments can leave the enclave through downloads, exports or mobile clients.
Enforcement evidence: keep the configuration exports, allow-lists and access reviews that show the authorizations are enforced.

Confirm with each vendor which of these controls can be configured and exported as evidence before you commit to a design.

What chat tooling alone does not satisfy

A chat enclave can enforce encryption, access and logging, but several CMMC Level 2 outcomes depend on decisions, training and paperwork that no platform makes for you. The cards below cover the gaps an assessor is most likely to probe, and what your team must own in addition to the software.

CUI flow policy and authorizations

Software can enforce a flow rule, but someone must first decide which CUI may enter chat, which channels and guests may receive it, and which external destinations are authorized. AC.L2-3.1.3 expects those decisions to be written down before configuration. Check that the policy names the approved sources, destinations and authorizations, and that the chat configuration matches it line by line.

User training on sharing CUI

Most CUI leaks in chat happen through ordinary behavior: pasting a spreadsheet excerpt into a public channel, forwarding a thread to a partner, or uploading a file to the wrong team. Training should define what counts as CUI for your contracts, show how to mark and move it, and explain what to do after a mistake. Keep training records, since assessors ask for evidence that users were taught.

Mobile and desktop client controls

Official mobile and desktop clients store messages and files on devices that the enclave does not run. Decide whether CUI may reach personal devices, and if so, enforce device management, screen lock, remote wipe and approved client versions. Confirm which controls your chosen platform provides for mobile apps and which you must add through your endpoint management tooling.

Federation and bridge governance

Federation or a bridge to Slack or Teams can move CUI outside your boundary in one step. Each external server, guest account and bridge needs an approval record, a documented purpose and a review cadence. Confirm whether the platform supports domain allow-lists and whether bridges are in scope of your system security plan before enabling them.

Backup, media and retention handling

Backups, database replicas and the shared file store for uploads all hold CUI and fall within the same protection requirements as live data. Confirm where backups are encrypted, who may restore them, how deleted files are purged from storage, and how retention settings apply to media. Mattermost high availability requires shared file storage on each node, so that storage needs the same controls as the application.

Assessor-facing SSP and evidence package

An assessor will expect a system security plan that describes the chat enclave boundary, its data flows and the responsible owner for each practice, plus evidence in final form. Audit records, configuration exports and training logs must be retained and reviewed on a schedule. Confirm with your assessor whether the audit features in Mattermost or Rocket.Chat editions you are considering meet the assessment scope before you rely on them.

What the July 2026 CMMC changes mean for chat planning now

The most important point for chat planning is that the schedule changed but the control set did not. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and the obligations under DFARS 252.204-7012 remain in place. The DoW CIO "About CMMC" page reports that implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. These sources do not agree on everything, so do not plan around either one alone.

Confirm your current obligations in writing with your contracting officer and your counsel before you commit budget or contract language to a date. Ask specifically which Level 2 self-assessment or affirmation applies to your contracts, whether any certification requirement is in your contract, and how the 60-day review is expected to affect the timeline. Record the answers in your System Security Plan so the chat enclave's scope matches what you have told the government.

Build the chat controls to NIST SP 800-171 Rev. 2 now, regardless of the schedule. The Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim, and CMMC Level 2 uses those same 110 requirements. Controls such as AC.L2-3.1.3 on CUI flow and SC.L2-3.13.8 on encryption in transit, which cannot be placed on a POA&M if not met, are the ones most likely to fail a chat enclave review. Evidence collected today for your Mattermost or Matrix enclave will still be useful whatever the final timeline turns out to be.

Questions buyers ask before a CUI chat enclave is built

Is Mattermost or Matrix better for handling CUI?

Neither platform is better for CUI by default. The choice depends on whether you need one organization's chat under central control (where Mattermost is a common fit, with a single Linux binary and PostgreSQL) or cross-organization federation with partners (where Matrix is the usual design). The CUI controls apply to whichever you pick: access restriction, encryption in transit, and audit logging. Confirm with your assessor how each platform's FIPS 140-3 status and audit features apply to your deployment, since the Mattermost pricing page ties FIPS compliance to its Enterprise plan. Federation also adds a flow-control question you must answer on paper before go-live, because CUI sent to an external server leaves your boundary.

Is a free edition enough for a CUI chat enclave?

Usually not without checking the feature list first. Rocket.Chat's free Starter plan includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption and retention, but its paid plans add tamper-evident audit trails of messages, files and sessions, and air-gapped deployment is not available on Starter. Mattermost places SSO and AD/LDAP sync from its Professional plan, and high availability and FIPS 140-3 compliance from Enterprise. Map each CUI control to a feature and confirm which edition provides it in writing before you choose a license tier.

How long does a CUI chat enclave build take, and what drives it?

The timeline depends on scope rather than on the chat software alone. The main drivers are the number of user populations and guest or partner access patterns, the identity integration, the number of CUI flows you must document (chat, file attachments, bots, mobile devices), the hosting environment, and the evidence you must produce. Mattermost high availability adds shared file storage and database replicas, which extend the work. Ask for a fixed-scope plan with phases and written acceptance criteria, and treat any duration without a stated scope as a sales estimate.

What does the work need from our IT and compliance staff?

The engagement needs named people with decision authority and time for reviews. On the IT side, you need identity administrators for SSO and directory sync, network staff for segmentation and load balancers, and database and storage owners. On the compliance side, you need someone who owns the System Security Plan, the CUI data flow diagram and the Plan of Action and Milestones (POA&M) decisions. Engineers also need access to your test environment early. Agree on these responsibilities in the written scope so that delays are visible and assigned.

Can our own team build and run a CUI chat enclave without a partner?

Your team can do it if it has the skills and time, but the risk sits in the evidence. The practices in NIST SP 800-171 Rev. 2 require documented policy, configuration and logs in final form, and each requirement is met only when every applicable assessment objective in NIST SP 800-171A (June 2018) has evidence. Many teams underestimate the monitoring, patching and audit review work that follows go-live. Assess your internal capacity against those tasks honestly, and consider a partner for the build, the evidence package or the run phase separately.

What recurs after go-live for a CUI chat enclave?

Recurring work is larger than most budgets assume. Mattermost ships a new server version in binary form on the 16th of each month, and the ESR line v11.7 supports until 2027-05-15, so you must choose a release track and test upgrades. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and unsupported versions lose security fixes and may lose mobile client compatibility. Other recurring items include access reviews, log review, backup testing and refreshing the evidence before each assessment. Ask any partner for the upgrade cadence and the evidence refresh process in their retainer scope.

Does DeployOpen certify that our chat enclave is CMMC compliant?

No. DeployOpen does not issue certifications, attestations or audit reports. For Level 2 certification, assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. DeployOpen can plan and implement the enclave, configure controls, and prepare the systems, controls and evidence that an assessor will examine. Note that the Department of War suspended CMMC Phase II on 13 July 2026, so confirm current assessment requirements with your contracting officer before you set a deadline.

How DeployOpen scopes and delivers a CUI chat enclave

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source chat inside your own infrastructure, including enclaves that handle CUI. We start from a written scope that ties each CMMC Level 2 practice to a specific control, configuration and piece of evidence, so your assessor and your team see the same boundary.

How we scope

We map which chat channels, direct messages, file shares and guest accounts will hold CUI and which will not.
The written scope names the platform, edition, hosting location, identity source and the network boundary around the enclave.
We agree deliverables, timelines and exclusions in writing before any work starts, since engagements are fixed-scope.

How we build

We deploy the chosen platform in your cloud account, data center or air-gapped network, with encryption in transit configured and verified.
We configure SSO, directory sync, audit logging and retention settings against the agreed control mapping.
We run security testing on the enclave and document findings, so gaps are fixed before evidence is collected for assessment.

How we hand over

You receive the system documentation, configuration records, control-to-evidence mapping and runbooks written for your assessor.
We document the upgrade and backup procedures, including how monthly server releases are tested and applied in your environment.
Handover includes walkthroughs with the administrators who will operate the enclave after the engagement closes.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
We can keep the control evidence current as platform versions change and as your assessment timeline is confirmed.
Final determinations on CMMC status rest with independent assessors and the CMMC Accreditation Body, not with DeployOpen.

Self-hosted team chat for CMMC and CUI