Notifications
Clear all
Topic starter
06/06/2026 11:28 am
TL;DR: Credential sharing through Slack, DMs, and free one-off tools leaves secrets with an indefinite shelf life and unclear oversight, according to ConductorOne. Embedding secret sharing inside the identity platform makes access control, auditability, and expiry part of the same governance plane that already governs who can reach what.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams handle secret sharing without using Slack or email?
A: Security teams should route secret sharing through a governed transfer workflow that enforces recipient identity, expiry, view limits, and audit logging.
Q: Why is secret sharing a governance issue and not just a user convenience problem?
A: Secret sharing creates an access decision about who can receive, retain, and reuse a credential.
Q: What do teams get wrong about sharing secrets through collaboration tools?
A: Teams often assume a message disappears when the task is done.
Practitioner guidance
- Remove credential exchange from general chat channels Block routine sharing of tokens, API keys, certificates, and config fragments through Slack, DMs, email threads, and ticket comments unless the platform enforces expiry, view limits, and audit records.
- Require identity-bound secret transfer for sensitive handoffs Use a governed sharing workflow that ties each secret exchange to an authenticated user, recipient list, and immutable audit trail, so the transfer is reviewable after the fact.
- Separate short-term transfer from long-term secrets management Keep one-time secret handoff, rotation, inventory, and offboarding in distinct controls so the convenience of a quick share does not become a substitute for lifecycle governance.
What's in the full announcement
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Browser-side encryption model details for one-time secret handoff
- Recipient authentication options for internal users and external contacts
- Expiration and view-limit handling for shared text, JSON, YAML, and files
- Product workflow for sharing secrets inside the identity platform rather than in chat
👉 Read ConductorOne's post on secret sharing inside the identity platform →
Secret sharing in identity platforms: what IAM teams need to know?
Explore further
06/06/2026 12:17 pm
Secret transfer is now an identity governance control, not a convenience feature. The moment a credential is handed off, the organisation is making an access decision about who can use, retain, and replay that secret. Chat tools and ad hoc sharing services do not provide the lifecycle evidence IAM teams need. Practitioners should treat secret exchange as part of the access plane, not the collaboration plane.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do organisations know if secret sharing controls are actually working?
A: They should look for fewer secrets in chat systems, fewer manual cleanup steps, complete audit records for each exchange, and a clear separation between temporary transfer and long-term credential lifecycle controls. If people still need to improvise, the control is not working.
👉 Read our full editorial: Secret sharing in identity platforms changes credential governance
