Zero shared passwords: eliminating credential risk in a multi-admin environment

The shared-password habit and why it persists

In most infrastructure teams, the security story around server credentials is quietly uncomfortable. Someone set up the servers, someone created a root password or an SSH key, and then — because it was convenient — they shared it. The password went into a shared notes document, a Slack message, a text file on a shared drive, or in many cases, a person's memory that gets transmitted verbally whenever a new team member joins. This is the norm, not the exception.

It persists because the alternatives have been genuinely painful. Proper privileged access management historically meant deploying expensive enterprise PAM software that required its own infrastructure, training, and ongoing maintenance. For a team of five engineers managing 30 servers, deploying a full CyberArk or BeyondTrust stack is overkill — not worth the time, the cost, or the complexity. So teams make a rational trade-off: accept the credential risk because the mitigation is too expensive.

The problem with that trade-off is that the risk doesn't feel real until it does. A shared password is invisible as a risk right up until it becomes the cause of an incident. Someone leaves the company. Someone's laptop gets compromised. Someone accidentally pastes the password into a log file. Someone shares it outside the team for a "just this once" situation that then becomes permanent. The credential exposure grows silently over time, and the team doesn't know they have a problem until they have a very visible problem.

The scale of the problem

The statistics around credential security make for uncomfortable reading. According to Verizon's 2024 Data Breach Investigations Report, compromised credentials are the leading cause of breaches — involved in over 80% of hacking incidents. IBM's Cost of a Data Breach report puts the average cost of a breach at $4.88 million in 2024, with breaches involving stolen credentials taking longer to identify and costing more to remediate than any other breach type.

These aren't abstract enterprise problems. Small and mid-size teams are disproportionately vulnerable precisely because they lack the dedicated security resources to enforce proper credential hygiene. A large enterprise has a dedicated security team, mandatory password manager policies, quarterly access reviews, and automated deprovisioning workflows. A five-person ops team has a Slack channel and good intentions.

The most dangerous credential risk in infrastructure environments isn't a sophisticated attack. It's the mundane accumulation of access that never gets cleaned up. The contractor who was given SSH access six months ago and technically still has it. The shared key that was created for a CI/CD pipeline that nobody maintains anymore. The former employee whose access was removed from the main systems but who's still listed as having the shared root password that was never rotated after they left. Each of these is a door left unlocked — and most teams couldn't tell you how many unlocked doors they have without spending days doing an audit.

How HashiCorp Vault changes the model

HashiCorp Vault is a secrets management system designed to solve exactly this problem. Instead of credentials being stored somewhere accessible — even if that somewhere is an "encrypted" shared notes app — Vault acts as a central, access-controlled repository where secrets are stored, versioned, and audited. Access to secrets is granted through Vault's own access control system, not by sharing the secret itself.

CortexShell integrates Vault as its native credential backend. When you add a server to CortexShell, the connection credentials go into Vault — not into a database field, not into a config file, not anywhere that a user or the application could read directly. When someone connects to that server through CortexShell, the platform retrieves the credential from Vault at the moment of connection, uses it, and never exposes it to the connecting user. The user experiences a seamless connection; they never see, handle, or transmit the credential itself.

This means that from the perspective of any individual engineer using CortexShell, there is no password to know, no key file to manage, and nothing to accidentally leak. They log into CortexShell with their own identity, connect to the servers they're permitted to access, and the underlying credential exchange happens invisibly and securely through Vault. The secret exists and is used — but no human ever has to touch it.

In CortexShell's interface, each server displays a small green dot when its credentials are properly stored in Vault. This visual indicator isn't decorative — it's a real-time confirmation that no plaintext credential exists outside of Vault for that server. When a green dot is missing, you know immediately that a server hasn't been fully migrated to the secure credential model and can prioritise fixing it.

Per-user access: the right credentials for the right people

The Vault integration solves the "nobody should see the password" problem. CortexShell's per-user access control system solves the equally important "not everyone should be able to connect to every server" problem. These two concerns are related but distinct, and both need to be addressed for a genuinely secure credential model.

In a typical shared-credentials environment, access is all-or-nothing. If you have the shared password, you have access to everything that password protects. This makes it difficult to implement least-privilege access — the security principle that users should only have access to the resources they actually need for their current responsibilities. Least privilege is both good security practice and a requirement under most compliance frameworks, but it's operationally impractical when credentials are shared.

CortexShell's access control model works at the individual server level. When you add a user to CortexShell, you explicitly tick which servers they can access. A junior developer can be given access to staging servers but not production. A contractor can be given access to the specific systems relevant to their engagement, and no others. A monitoring user can be given read-only visibility without the ability to connect interactively. This granularity doesn't require individual accounts on each server — it's managed centrally in CortexShell, and enforced at every layer, including through the AI assistant CortexShell.

The practical consequence is that access management becomes lightweight and maintainable. Adding a new team member? Create their CortexShell account, tick the servers they need. A contractor finishes their engagement? Remove their CortexShell account. Done — no key rotation, no password change, no manual deprovisioning across each individual server. The access boundary is in one place, and changing it takes seconds.

The audit trail that credentials alone can't provide

Even with strong credentials and access control, a critical question remains: what did people actually do when they were connected? A credential system tells you who connected and when. It doesn't tell you what commands were run, what files were accessed, or what changes were made. Without that information, the credential layer is protecting access to a black box.

CortexShell's audit log captures every connection event with full context: the user identity, the server connected to, the timestamp, the source IP address, and the duration. Combined with session recording — which captures every command and every output from every terminal session — this gives you complete visibility into the actual activity on your servers, not just the access events.

For incident investigation, this is transformative. When something goes wrong on a production server, the first question is always "what was done to this server and by whom?" Without session recordings and a comprehensive audit log, answering that question means relying on people's memory and whatever logs the server itself happened to capture. With CortexShell, you can replay the exact terminal session that preceded the incident, in order, at variable speed. You don't need to reconstruct what happened — you can watch it.

For compliance purposes, this combination of Vault-managed credentials, per-user access control, and full session recording provides a level of privileged access accountability that many organisations struggle to achieve even with dedicated PAM tools. PCI DSS, ISO 27001, SOC 2, and HIPAA all have requirements around privileged access management and audit trails — CortexShell addresses these requirements without requiring a separate PAM deployment.

What happens when someone leaves the team

Offboarding is where the weaknesses in shared-credential models become most visible. When a team member leaves, you need to revoke their access. In a shared-password model, that means rotating every password or SSH key they had access to, which means updating every system that uses those credentials, which in practice means a multi-hour exercise that often gets deferred ("we'll do it when things are less busy") and sometimes never fully completed.

CortexShell's approach to offboarding is a single action: disable or delete the departing user's CortexShell account. Their access to every server disappears immediately. No credential rotation required. No key removal from individual authorized_keys files. No checking whether they had access to that database you forgot to include in the audit. The access boundary was in one place, and removing it takes seconds.

This matters most in high-risk situations: a hostile departure, a sudden termination, a security incident involving a compromised account. In those cases, the ability to cut access completely and immediately is the difference between a contained incident and an extended exposure window. With CortexShell, your response time is bounded by how quickly you can click "disable account" — not by how many individual systems you need to update across your infrastructure.

Meeting compliance requirements without changing workflows

A recurring concern when teams consider improving their credential security is that better security means more friction. Complicated authentication flows, extra approval steps, slower access to critical systems in an emergency. This concern is understandable — security that slows things down tends to get worked around, which defeats its purpose.

The design principle behind CortexShell's credential management is that the secure path should also be the easy path. Engineers connect to servers the same way they always have — click a server, open a terminal — with the difference that they never have to handle a credential themselves. Vault's credential retrieval happens in the background without any user interaction. The experience is actually smoother than managing SSH key files manually or looking up passwords from a shared vault.

Compliance reporting is similarly handled without additional effort. CortexShell's audit log is always running; there's nothing extra to set up. When an auditor asks for evidence of privileged access controls, you export the relevant log data. When a security review asks whether access was restricted after someone left the team, you point to the offboarding timestamp in the audit log. The compliance evidence accumulates as a natural by-product of using the platform, not as a separate administrative burden.

The path from shared passwords to zero-knowledge access

Migrating from a shared-credential model to Vault-backed, per-user access isn't an overnight project, but it's more straightforward than most teams expect. CortexShell is designed to accommodate the migration in stages: you can bring servers into the Vault model one at a time, and the green-dot indicator on each server tells you clearly where you are in the migration at any given moment.

A typical migration follows this sequence: audit existing access (which is often more sprawling than anyone expected), create individual CortexShell accounts for each team member, add servers to CortexShell with Vault-stored credentials, and gradually retire the shared credentials that were previously used. The team gets the benefit of centralised access management immediately, while the Vault migration proceeds at whatever pace is comfortable.

The end state is straightforward to describe but genuinely impactful to operate: no individual on your team knows any server credentials. They connect through CortexShell, which handles the authentication transparently. When someone leaves, their access disappears immediately. When an auditor asks who had access to a particular server on a particular date, the answer is in the audit log. And when a security review asks whether your privileged access management meets best practices, the answer is yes — not because you deployed an expensive enterprise tool, but because CortexShell integrated the right security architecture into the platform your team uses every day.