Email and instant messaging create risk because forwarded credentials can be intercepted, copied, or leaked outside the sender’s control. Once a password leaves a governed access model, there is no reliable way to limit reuse or exposure. A secure process should preserve permissioning, support revocation, and ensure changes propagate automatically to everyone who still needs access.
Why email and instant message sharing creates operational exposure
Passwords are operational controls, not just pieces of text. When they are sent through email or instant message, they leave the governed access path that should control who can use them, how long they remain valid, and when they are revoked. That creates a direct gap between intent and enforceable access control, especially if the message is forwarded, copied, archived, or synced across devices.
The practical problem is not only interception. Once a password is distributed in a channel built for conversation rather than access governance, the organisation loses reliable visibility into where that secret has gone and whether it is still being reused. A credential handoff should be traceable, time-bound, and revocable; email and chat do not provide that by default.
How the risk expands beyond the first recipient
The first recipient is rarely the only exposure point. Email may be retained in inboxes, backups, search indices, mail clients, and server-side archives, while instant messages may persist in threads, notifications, exported logs, screenshots, or personal devices. Each additional copy expands the attack surface and increases the chance that a password outlives the need for access.
That persistence matters because credential compromise is often opportunistic. A password shared once can later be found by an unintended insider, a compromised endpoint, or anyone with access to the communication system. If the same password is reused elsewhere, the operational impact can spread well beyond the original account or system.
What a safer access pattern needs to preserve
A secure process should preserve permissioning, support revocation, and ensure changes propagate automatically to everyone who still needs access. In practice, that means the access grant should be tied to an identity or group policy rather than embedded in a message thread, so removal of access is possible without hunting through old conversations.
For shared operational access, the better model is to avoid distributing the secret itself wherever possible and instead use governed access methods that can be audited, rotated, and expired. If the business process still depends on a password handoff, then the organisation has accepted a fragile control path that is difficult to review and easy to lose track of over time.
Risk and Threat Considerations
Sharing passwords through email or instant message creates exposure because the credential can be copied, retained, or forwarded outside the sender’s control. The risk becomes material when the password grants access to production systems, shared admin accounts, finance tools, customer data, or any system where delayed revocation would extend the blast radius.
Failure mechanism: The control fails when a secret is treated as ordinary content rather than governed access material, so the organisation cannot reliably bound its distribution, lifetime, or reuse.
Impact: A leaked or stale password can enable unauthorised access, duplicate use across systems, weak accountability, and delayed recovery after a change or suspected compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passwords shared by message need controlled lifecycle, rotation, and revocation. |
| AC-6 — Least Privilege | Shared passwords often expand access beyond what the task needs. | |
| Recommendation — Enforce IA-5 to manage password lifecycle and revoke shared credentials quickly. Apply AC-6 to keep access narrowly scoped and avoid shared standing credentials. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | The question is about mishandling authentication information during sharing. |
| Recommendation — Protect authentication information with controlled issue, transfer, and revocation processes. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Operational risk here comes from uncontrolled access distribution and revocation gaps. |
| Recommendation — Use CIS-6 to centralise access and remove ad hoc password sharing. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | The answer depends on preserving permissioning and revocation after sharing. |
| PR.AA-01 — Identity Management, Authentication and Access Control | The subject is fundamentally about access control around credentials. | |
| Recommendation — Use PR.AA-05 to manage permissions through revocable, governed access paths. Use PR.AA-01 to ensure access is issued and managed through controlled identity processes. | ||
Practitioner Guidance
What to prioritise: Treat any password being shared in email or chat as an operational exception that needs replacement, not normalization. If the account is important enough to be shared informally, it is important enough to move to a controlled access method with revocation and auditability.
What to verify: Confirm whether the secret is tied to a named owner, whether it can be rotated without breaking dependent workflows, and whether every recipient can be removed from access without manual cleanup in multiple systems. If not, the process is not operationally robust.
Common mistake: Teams often focus on whether the message is encrypted in transit and ignore the larger issue, which is the long-lived spread of the credential after delivery. Transport protection does not solve reuse, forwarding, screenshots, or mailbox retention.
Practitioner takeaway: The key judgement is whether the organisation can revoke and re-issue access as cleanly as it can send a message. If it cannot, the password share is a business continuity and security liability, not a convenience.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
