Password sprawl at UTP shows why centralized secret sharing matters

At a glance

What this is: University of Toronto Press unified password sharing and secret handling after fragmented tools made secure sharing and central control impractical.

Why it matters: It matters because the same pattern shows up across human, NHI, and machine access: when credentials sprawl across tools and teams, governance, auditability, and secure sharing all degrade.

By the numbers:

• The UTP team estimates that they save 10 hours of IT time per week.

👉 Read Bitwarden's case study on centralized password sharing at University of Toronto Press

Context

Password sprawl is a governance problem, not just a convenience problem. When different teams use different password managers, administrators lose centralized control over who can share credentials, who can revoke access, and how secrets are handled across the organisation. That is a familiar failure mode in IAM and secrets management, especially where operational teams are allowed to solve access problems locally.

University of Toronto Press ran into that exact boundary condition. The issue was not whether teams knew what a password manager was, but whether the organisation could impose one consistent control plane for sharing, group access, and automation. For identity programmes, the lesson is straightforward: if credential handling depends on user choice, the programme does not have a programme.

Key questions

Q: How should teams govern password sharing across departments?

A: Use one centrally managed platform, not separate tools chosen by individual teams. Put shared credentials into team-specific groups or collections, apply least privilege to who can read and add secrets, and review membership on a regular access-review cycle. If sharing remains informal, revocation and auditability will always lag behind actual usage.

Q: Why do fragmented password managers create security risk?

A: Fragmentation breaks centralized policy. When each team uses a different manager, administrators lose a single view of who can access secrets, how they are shared, and whether revocation is complete. That creates blind spots in audit, makes offboarding harder, and increases the chance that stale credentials remain in circulation.

Q: What do teams get wrong about secure secret sharing?

A: They often focus on encryption in transit and ignore lifecycle control. Secure delivery matters, but the bigger question is who can create, redistribute, and retire the secret afterward. Without ownership, review, and revocation, secret sharing becomes a long-lived access path instead of a controlled exception.

Q: How do organisations know whether password governance is actually working?

A: Look for one authoritative system, clear ownership of each collection or secret group, and a repeatable process for review and revocation. If staff still rely on ad hoc sharing, local tools, or manual copying to get work done, the governance model is not working even if the vault is technically deployed.

Technical breakdown

Why fragmented password managers break governance

A password manager only becomes an identity control when the organisation can standardise policy, grouping, and auditing around it. If users adopt different tools, secret ownership becomes distributed across local habits rather than centrally governed access rules. That breaks the chain needed for review, revocation, and incident response. In practice, fragmented tooling also makes it difficult to distinguish routine sharing from risky shadow handling of secrets, because each repository follows its own conventions and permissions model.

Practical implication: consolidate secret handling into one governed system so access review, logging, and revocation operate on the same policy model.

Collections as a shared-access control pattern

Collections are effectively team-scoped access containers for passwords and secrets. They separate who may read, add, or manage credentials from the underlying secret itself, which is why they map well to departmental or function-based governance. The important technical point is that the control is not the password vault alone, but the permission structure around it. That structure gives administrators a way to align sharing with operational roles rather than ad hoc requests, reducing both leakage risk and support friction.

Practical implication: design shared secret access around team and function boundaries, then review collection membership like any other privileged access.

How secret sending and CLI automation change the attack surface

Encrypted secret-sharing workflows and CLI automation extend password management beyond a browser UI into operational pipelines. That can reduce manual copying, but it also shifts risk into scripting, token handling, and automated handoff paths. The security benefit comes from encrypting the shared content and constraining delivery, while the governance challenge is ensuring the automation itself does not become an unmanaged secret channel. In identity terms, the control plane must cover both human workflows and machine-assisted distribution.

Practical implication: treat CLI-based secret workflows as governed identity processes, not just admin convenience features.

Threat narrative

Attacker objective: The attacker or negligent insider gains access to credentials that can be reused without centralized detection or revocation.

1. Entry occurs through inconsistent local password management, where different teams store and share credentials in separate tools with no central policy enforcement.
2. Escalation happens when access to shared secrets cannot be standardised or revoked cleanly, which increases the chance of unauthorized reuse or uncontrolled distribution.
3. Impact is slower response, weaker auditability, and higher exposure to credential misuse because the organisation cannot reliably see or govern all secret-sharing paths.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Centralized password governance is the real control, not the vault itself. The article shows that the organisation’s problem was not a lack of password tools, but a lack of one enforced access and sharing model. When every team chooses its own manager, identity policy fragments into local practice and the enterprise loses control over who can share, revoke, and audit secrets. The practical conclusion is that password management only works as governance when the organisation owns the control plane.

Shared collections are a team-bound identity boundary, not a convenience feature. By grouping secrets into team-specific collections, UTP turned password sharing into an access management pattern instead of an informal habit. That matters because collection membership becomes reviewable governance data, while ad hoc sharing does not. Practitioners should treat those group boundaries as privileged access scope and manage them with the same discipline as other entitlements.

Secret sharing without lifecycle control creates hidden access persistence. The article makes clear that secure transmission is only part of the problem. If credentials are shared faster than they are reviewed, revoked, or reassigned, the organisation inherits standing access through informal channels. The implication is that credential lifecycle, not just encryption, determines whether sharing remains governable over time.

Automation changes the operational model of secrets management. Once password generation and sharing move into CLI-driven workflows, the issue is no longer just user behaviour but process integrity. That creates a stronger case for policy-backed automation, because manual handling becomes the weak link. Practitioners should align automation with governed secret workflows rather than treating scripts as outside the identity programme.

UTP’s outcome reflects a wider identity truth: security improves when usability is standardized. Teams do not abandon control because they prefer risk; they abandon it when the approved path is harder than the workaround. A central system that supports group-based sharing, secure send, and automation reduces the incentive to create shadow processes. Identity teams should design for adoption or expect policy bypass at the edges.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, 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.
• That is why Ultimate Guide to NHIs , Key Research and Survey Results remains the best next step for teams trying to close secret sprawl.

What this signals

Secret sprawl is usually an adoption problem before it is a tooling problem. If teams cannot share credentials cleanly inside one governed system, they will create parallel methods that escape policy. The practical signal for identity leaders is to measure how many secret paths exist outside the approved platform and eliminate the ones that cannot be reviewed.

Credential handling is increasingly a cross-domain control issue. The same governance pattern applies whether the subject is a human user, a service account, or a scripted workflow. The more automation enters the process, the more important it becomes to define ownership, review cadence, and revocation authority around the secret itself rather than the tool used to store it.

With 96% of organisations storing secrets outside secrets managers, according to Ultimate Guide to NHIs, the control gap is structural, not isolated. That figure tells practitioners to focus on discovery and consolidation first, then on workflow hardening and access governance. The next programme milestone is to make unmanaged secret locations visible before they become normalised.

For practitioners

• Consolidate password management into one governed control plane Replace locally chosen password managers with a single policy-enforced platform so sharing, audit logging, and revocation operate consistently across teams.
• Map shared secrets to team-based collections Assign credentials to collections aligned to departments, functions, or operational groups, then review membership as part of privileged access governance.
• Govern CLI-driven secret workflows as identity processes Treat scripting paths that generate or distribute credentials as part of the identity programme, with logging, approval boundaries, and clear ownership.
• Review secret sharing for lifecycle gaps Check whether shared passwords are still needed, who can still access them, and whether old sharing paths remain active after role changes or team moves.

Key takeaways

• Fragmented password tools create governance failure because they remove centralized control over sharing, audit, and revocation.
• The evidence from UTP shows that secure collections and automation can reduce operational friction while still tightening access discipline.
• Identity teams should treat secret sharing as a governed lifecycle process, not as an informal convenience layer for users and admins.

Key terms

• Secret Sharing: Secret sharing is the controlled distribution of credentials, tokens, or other sensitive access material to approved people or systems. In an identity programme, it is only safe when ownership, audience, logging, and revocation are all defined and enforced.
• Collection-Based Access: Collection-based access groups related secrets into a governed permission boundary. It allows teams to manage credentials by function or role rather than by individual request, which makes review and revocation much more tractable.
• Secrets Manager: A secrets manager is a system for storing, controlling, and auditing credentials outside code and ad hoc file locations. Its value depends on whether the organisation actually uses it as the authoritative control point rather than one of several parallel storage habits.

What's in the full article

Bitwarden's full post covers the operational detail this post intentionally leaves for the source:

• The team-by-team collection setup UTP used to separate developer, retail support, and privileged administrator access.
• The Bitwarden Send workflow for encrypted one-to-one secret delivery, including expiration and download limits.
• The CLI-based automation path Rodness used for onboarding and password distribution in scripts.
• The specific operational benefits UTP reported after consolidation, including the estimated weekly time savings.

👉 Bitwarden's full post covers team collections, secure send, and CLI automation in more operational detail.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or maturing governance across your environment, it is worth exploring.