They usually cannot prove ownership, access scope, revocation, or traceability well enough for supervisory scrutiny. If a secret can be copied, forwarded, or accessed outside a governed system, the organisation loses the ability to demonstrate control over who used it and when.
Why This Matters for Security Teams
NIS2 is not asking organisations to merely keep secrets private. It expects them to prove control over credentials across their lifecycle: issuance, access scope, revocation, and traceability. Shared spreadsheets and chat tools are built for collaboration, not governed credential handling, so they rarely provide defensible evidence when auditors or supervisors ask who had access, when that access changed, and whether the secret was still valid at the time of use.
This is why “everyone in the team can see it” becomes a compliance problem. A copied API key in a spreadsheet or a pasted token in chat can be forwarded, exported, or retained long after the original need has ended. The result is a gap between informal convenience and the accountability NIS2 expects under the NIS2 Directive. NHIMG research also shows that 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which is a strong signal that the problem is not theoretical but operational.
Practitioners should treat shared tools as evidence of process failure, not just user behaviour. In practice, many security teams encounter secret exposure only after a spreadsheet or chat thread has already become the de facto system of record.
How It Works in Practice
The practical issue is that shared spreadsheets and chat platforms do not function as identity governance systems. They can store text, but they do not reliably enforce least privilege, time-bound access, approval workflows, or revocation. That makes it difficult to demonstrate that a credential was accessible only to authorised individuals for a legitimate purpose. The OWASP Non-Human Identity Top 10 frames this well: secrets handling is not just about secrecy, it is about lifecycle control and misuse resistance.
In a NIS2 context, a better practice is to move secrets into governed systems that can show ownership and state. That usually means:
- Storing secrets in a dedicated vault or secrets manager rather than in shared documents or chat histories.
- Issuing access through named roles or workload identities, with logging that ties each request to a person, system, or service account.
- Using short-lived credentials where possible so revoked access actually means revoked access, not just “hidden from view.”
- Maintaining immutable audit trails for retrieval, rotation, and emergency break-glass use.
Current guidance suggests that evidence quality matters as much as technical control. A board or regulator does not need to see every secret value, but it does need to see who approved access, how long the credential was valid, and whether it was removed after use. NHIMG’s Guide to the Secret Sprawl Challenge highlights how quickly uncontrolled distribution turns into hidden exposure paths. In practice, the more a secret is copied between systems, the harder it becomes to reconstruct ownership and revocation with confidence. These controls tend to break down in fast-moving incident response channels because urgency encourages copying secrets into chat instead of routing them through governed access paths.
Common Variations and Edge Cases
Tighter credential governance often increases friction, so organisations must balance speed against defensibility. That tradeoff becomes sharper in small teams, emergency operations, and hybrid environments where staff already rely on shared channels to move quickly.
There is no universal standard for every edge case, but the direction of travel is clear: exceptions should be controlled, time-limited, and recorded. For example, a break-glass process may justify temporary chat-based coordination, but the secret itself should still be retrieved from a governed system and revoked immediately after use. The same applies when teams manage multiple cloud accounts or outsourced operations, where access paths may be distributed and informal workarounds are tempting. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with human IAM, which helps explain why spreadsheet-based controls persist.
Shared tools can also create false confidence because they leave a visible trail, but visibility is not the same as governance. A chat log can show that a secret was posted; it cannot reliably prove revocation, scope limitation, or whether the credential was later copied elsewhere. That is why NIS2-grade handling requires systems that can enforce and evidence access, not just record conversation. Organisations that keep relying on collaboration tools for secrets usually discover the audit gap only after an incident or supervisory review has already made it expensive.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret lifecycle control and rotation failures in shared tools. |
| NIST CSF 2.0 | PR.AA-01 | Supports identity proofing, access control, and auditability for credentials. |
| NIS2 | NIS2 demands demonstrable control over credential access, scope, and revocation. |
Replace informal sharing with evidence-backed credential governance and revocation records.
