Notifications
Clear all
Topic starter
10/07/2026 9:17 pm
TL;DR: Shared accounts remain common across frontline, legacy, and contractor workflows, but shared passwords create weak attribution, support overhead, and compliance gaps, according to Secret Double Octopus. Passwordless verification can reduce exposure, but the governance problem is still individual accountability and auditable access control, not just better login UX.
NHIMG editorial — based on content published by Secret Double Octopus: How MSPs Revolutionize Shared Accounts Management
Questions worth separating out
Q: What breaks when multiple people use the same shared account password?
A: The main failure is accountability.
Q: Why do shared accounts create more governance risk in MSP environments?
A: MSPs inherit the operational and compliance burden of proving access control across many client workflows.
Q: How can security teams reduce risk without redesigning legacy shared workflows?
A: They can place strong identity verification in front of the shared account and keep the backend password hidden from users.
Practitioner guidance
- Separate shared-account governance from shared-password handling Inventory which client workflows genuinely require shared accounts, then remove user knowledge of the backend password wherever the workflow must remain.
- Require individual verification before shared access is granted Place phishing-resistant authentication in front of the shared account so every session is tied to a specific person, even when the resource itself remains shared.
- Document who can use each shared account and why Maintain an access register that ties each shared account to approved users, business purpose, and review owner so auditors can test accountability, not just credential storage.
What's in the full article
Secret Double Octopus's full blog post covers the operational detail this post intentionally leaves for the source:
- Deployment examples across shared workstations, legacy applications, and remote access workflows
- How the ZeroPassword approach fits alongside existing authentication and directory infrastructure
- Operational arguments for reducing password reset tickets and improving attribution evidence
- The source's discussion of when shared accounts remain necessary in regulated and legacy environments
👉 Read Secret Double Octopus's guidance on securing shared accounts without shared passwords →
Shared accounts security for MSPs: are passwordless controls enough?
Explore further
10/07/2026 9:40 pm
Shared-account risk is fundamentally an attribution problem, not just a password problem. When multiple people use the same credential, the control plane cannot reliably answer who did what and when. That breaks auditability, complicates evidence collection, and turns offboarding into a brittle credential-change exercise rather than a lifecycle process. The practitioner conclusion is simple: if identity cannot be attributed, governance is incomplete.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to GitGuardian & CyberArk.
A question worth separating out:
Q: What should organisations review first when shared accounts are still necessary?
A: Start with the highest-risk shared accounts used for admin, support, contractor, or emergency access. Then verify that each one has a named business owner, approved user list, and offboarding trigger. If those three elements are missing, the account is operationally convenient but governance-poor.
👉 Read our full editorial: Shared accounts security for MSPs: why passwordless matters
