The answer to “are passwords in email compliant cmmc” is usually no: a plaintext password sent in an email or Teams chat should not be treated as compliant with CMMC 2.0 Level 2 practice IA.L2-3.5.10. The practice requires passwords to be cryptographically protected when stored and transmitted, while an ordinary message leaves a readable credential in mailboxes, chat history, exports, backups, and potentially support or discovery tools. Use an approved password manager, a secure account-activation process, or a protected authentication channel instead.
What does are passwords in email compliant cmmc mean under IA.L2-3.5.10?
NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice IA.L2-3.5.10 state:
“Store and transmit only cryptographically protected passwords.”
For a sole IT administrator, the wording can sound abstract, but the operational meaning is straightforward: do not let a readable password sit in a database, spreadsheet, email thread, Teams conversation, ticket, script, or log. Systems should keep a protected password verifier, and users should submit passwords only through a protected authentication process.
- “Store” means every place a password can remain after use. For user accounts, the application should store a one-way password hash rather than the original password. For operational credentials that must be retrieved, such as a shared service account, use an approved encrypted secrets or password-management system with tightly controlled access.
- “Transmit” means every time a password moves between a person, browser, application, device, or service. A login page protected by
HTTPSand modern TLS is a normal example. A readable password pasted into email or Teams is not a safe substitute for that protected login flow. - “Only cryptographically protected” means encryption or one-way cryptographic transformation must protect the credential itself. Merely limiting who can see a mailbox, chat channel, or spreadsheet is access control, not password protection.
The implementation note for this practice emphasizes one-way functions, commonly called password hashing. A proper password verifier cannot be converted back into the original password under normal conditions. That does not make weak passwords safe, however: a weak password can still be guessed offline if an attacker obtains its hash. Password complexity and screening requirements are addressed separately under IA.L2-3.5.7.
Do not solve the problem by emailing a password hash. Depending on the system, a hash may be replayable, useful for cracking attempts, or otherwise sensitive authentication material. The better answer is to avoid transmitting the credential outside an approved authentication or credential-sharing mechanism.
Who must follow IA.L2-3.5.10, and when does it apply?
This requirement applies to passwords used by systems within the CMMC assessment scope, including systems that process, store, or transmit CUI and the security systems that protect them. It covers ordinary employee accounts, privileged administrator accounts, VPN credentials, network-device accounts, application accounts, service accounts, database credentials, and passwords shared with approved third parties.
For a small organization, the practical boundary is often wider than the primary CUI repository. If Microsoft 365 email carries CUI, for example, the Entra ID tenant, endpoint-management platform, VPN, backup platform, firewall administration interface, and support systems that can affect that environment may all be relevant to the assessment scope.
The requirement is triggered at every credential-handling event, not just during a normal user login:
- Creating a new employee, contractor, vendor, or administrator account.
- Resetting a forgotten password or issuing a temporary credential.
- Sharing access to a shared mailbox, network appliance, application, or service account.
- Configuring an application, scheduled task, integration, backup job, or script that needs a secret.
- Documenting credentials in tickets, onboarding instructions, troubleshooting notes, or emergency procedures.
- Authenticating to a portal, VPN, remote-access tool, web application, or cloud service.
A user’s personal password for a system entirely outside the CMMC boundary may not be an assessed item. But once a password grants access to an in-scope asset, treats CUI, or protects the environment that supports CUI, it belongs in your IA.L2-3.5.10 process.
What does compliant password protection look like in practice?
An assessor is looking for more than a policy saying “do not email passwords.” They will normally want to see that the technology, normal workflow, and evidence all support the rule. The following examples show what that can look like for a one-person IT function.
| Situation | Compliant practice | Useful assessment evidence |
|---|---|---|
| Employee access to Microsoft 365 and CUI files | Users authenticate through Microsoft Entra ID over HTTPS; the organization does not store user passwords in a local spreadsheet or application database. |
Entra ID configuration screenshots, conditional access settings, onboarding procedure, and a sample sign-in workflow. |
| New-user onboarding | The administrator creates the account and sends an account-activation or password-reset link. The user sets the password directly in the approved identity platform rather than receiving a readable temporary password by email. | Written onboarding procedure, Entra ID “force password change” settings where used, and a redacted onboarding ticket. |
| Shared firewall or vendor portal credential | The credential is stored in Bitwarden Enterprise, 1Password Business, or another approved password manager. Access is shared to a named group, not pasted into Teams or a ticket. | Password-manager organization settings, group membership, item access history where available, and the password-sharing procedure. |
| Application or backup service account | A service credential is held in a protected secret store such as Azure Key Vault and retrieved by the authorized application or administrator. It is not hard-coded in a script or saved in a configuration file in plaintext. | Azure Key Vault access policies, secret inventory, redacted application configuration, and evidence of rotation or review. |
Consider Northline Circuits, an 84-person PCB manufacturer using Microsoft 365, Entra ID, JobBOSS² ERP, Altium 365, Fortinet remote access, and a managed backup platform. The part-time IT administrator receives a request from production to give a new process engineer access to the ERP and controlled design files. A compliant workflow is to create the Entra ID account, send an activation link, assign the required groups, and have the engineer set their own password in the identity service. No temporary password appears in the onboarding email, Teams channel, or help-desk ticket.
In the same environment, suppose a field-service vendor needs access to a protected support portal used for a CNC drilling system. Sending the password in Teams and the username by email is not a compliant “split-channel” workaround; both systems still retain readable pieces of the credential. A better approach is to create a named vendor account with least privilege and MFA, set an expiry date, and use the portal’s password-reset or invitation workflow. If a shared credential is truly unavoidable, share it through the approved password vault and remove access when the service engagement ends.
For password storage, remember the difference between a password verifier and a password secret. An application that validates a user password should store a one-way verifier, preferably using a modern adaptive password-hashing method such as Argon2, bcrypt, PBKDF2, or the platform’s approved equivalent. A service account password may need to be recovered by an authorized service, so it should be encrypted in a managed vault with access controls, not hashed in a way that makes the service unable to use it.
How can a sole IT admin make this manageable?
You do not need to inspect every message manually. Make the safe workflow the easy workflow: publish one approved password manager, document one onboarding and reset method, prohibit credentials in email, Teams, tickets, and documentation, and use named accounts wherever possible. Review the small number of shared credentials quarterly, especially administrator, vendor, firewall, ERP, backup, and manufacturing-system accounts.
Your policy can be brief but should be precise: passwords must not be stored or sent in plaintext; user password verifiers must be one-way cryptographically protected; and recoverable operational passwords must remain in an approved encrypted credential store. Pair that policy with screenshots and a few redacted examples showing that people actually use the process.
Frequently asked questions about password transmission and storage
Can I send a temporary password by email for CMMC?
Generally, no. Even a temporary password is a readable credential stored in the sender’s mailbox, recipient’s mailbox, retention systems, backups, and possibly email-security tooling. Send a password-reset or account-activation link instead, so the user creates the password through the approved authentication service.
Are Teams chat passwords compliant with CMMC?
Usually no. Microsoft Teams protects communications in transit and provides platform security controls, but pasting a readable password into a chat creates a persistent, user-readable credential record. Use a password manager’s secure sharing feature or an identity-platform invitation workflow.
Does TLS make emailed passwords compliant?
No, not by itself. TLS can protect a message while it travels between systems, but it does not eliminate the readable password stored in mailboxes, message archives, backups, and chat history. TLS is appropriate for a login session, not a reason to distribute passwords in messages.
How should I share a vendor password under CMMC?
Prefer a named, least-privileged vendor account with MFA and an expiration date. If a shared password is unavoidable, place it in the approved encrypted password manager, grant access only to the vendor’s authorized named user or group, and remove that access promptly after the work is complete.
Next step: Search your onboarding emails, Teams support channels, and help-desk templates this week, then replace any password-sharing language with an approved reset-link or password-vault workflow.
