Weak passwords are still one of the easiest ways into an environment.
That hasn't changed. What has changed is the expectation around how you control it.
If you're going through SOC 2, this is not one of those areas where you can get by with a decent policy and some good intentions. Auditors are going to look at how credentials are actually handled in your environment, not what your handbook says should happen.
This is where a lot of companies start to wobble.
The gap between the policy and the environment
On paper, most organizations look fine. Everyone has unique credentials, MFA is enabled, passwords are secure, access is controlled.
Then you look at how things operate day to day. Shared logins for critical systems. Passwords sitting in browsers. Credentials passed around in Teams or Slack. A spreadsheet labeled "logins" that everyone quietly depends on and nobody will admit to using.
None of this is rare. It's normal, and it stays invisible right up until someone asks for evidence.
What SOC 2 makes you prove
SOC 2 is not evaluating your intent. It's evaluating whether your controls exist and whether they operate.
For credentials, that means answering a specific set of questions with artifacts rather than assurances. Who has access to this system right now. How that access was granted and by whom. When it was last reviewed. What happened the last time someone left.
If the answer is that you require strong passwords and trust your team, you're going to have a bad time. This is the point where password management stops being a convenience and starts being infrastructure.
Where it usually breaks
Four patterns show up repeatedly.
Shared accounts destroy accountability. If five people use the same login, you don't have control. You have plausible deniability. There is no version of this that survives a walkthrough, because the auditor's first question is which of the five people performed the action in the log.
Storage is unstructured. Browsers, notes apps, internal documents, personal phones. Everyone has a system and none of it is governed, which means no one can produce an inventory of where credentials live.
Access is never cleaned up. People change roles, move teams, and leave. Their access outlasts the reason it was granted. This is the same movement problem that undermines compliance automation, and it has the same cause: nothing in the environment triggers removal.
MFA has exceptions. There is usually a legacy system or a service account that could not be covered. Those exceptions tend to be the weakest points in the environment, and they are rarely documented anywhere an auditor can find them.
None of this registers as a problem until someone asks you to prove control. Then it arrives all at once.
What a password manager is actually for
A password manager is not interesting because it stores passwords. Plenty of insecure things store passwords.
It matters because it produces a record. Credentials live in one governed place, access is tied to individual users rather than shared logins, access can be shared without exposing the password itself, revocation is immediate, and there is a log of who accessed what and when.
That last item is what changes an audit conversation. You stop explaining your process and start showing it.
Deploying it so it actually holds
Recommending a password manager is the easy part. Making it the path of least resistance is the work, and it comes down to four things.
Provisioning runs through SCIM from Entra ID, so vault access follows identity. When someone is disabled in Entra, their vault access goes with them, and neither event depends on somebody remembering to do it.
Deployment goes out through Intune rather than an email asking people to install something. Enforced, not optional. A password manager that half the company installed is a password manager that produced no control at all.
Sharing is structured around groups tied to roles, not around individuals accumulating credentials. This is what makes a role change survivable: you move the person between groups instead of auditing what they personally hold.
And usage gets checked. Without that, you have built a nicer place for passwords to sit while people keep doing exactly what they were doing before.
What we actually show an auditor
We use Dashlane, and the part that matters at audit time is the reporting rather than the vault.
We track password health across the environment: weak credentials, reused credentials, and credentials that have turned up in known breaches. Dashlane also surfaces credentials appearing on the dark web, and it finds them regularly. Those reports are what we use to drive users to change passwords, with the change recorded.
The score itself is not the control. A dashboard showing a good number is the same trap that catches organizations relying on compliance automation without process behind it. What we present to an auditor is the loop: the report identified these credentials as compromised or reused, these users were required to change them, and here is the record showing they did, on these dates.
That is a control operating. A password health score with nothing attached to it is a metric.
The question it has to answer
Password management exists to answer one question clearly. Can you show that access to your systems is controlled, and can you show what you did when it wasn't?
If the answer is no, it doesn't matter how strong your passwords are supposed to be. You don't have a control. You have a gap, and it's the same gap that both auditors and attackers go looking for.
Credential management is one of the simplest areas to tighten and one of the fastest to expose problems if it gets ignored. It doesn't need to be sophisticated. It needs to be enforced, structured around roles, and observable enough that you can produce evidence without a scramble.
If you're preparing for an audit and credentials are the part you're least sure about, that's usually the right place to start. It's part of how we approach compliance readiness generally.