Home/Questions/Access control and privilege/Password manager for privileged accounts
Access control and privilege

Does the Applicant use a password manager to maintain master/privileged passwords used to access client systems and IT infrastructure?

The question is really about where your most valuable credentials live, and whether that place has its own access control and audit trail.

Attested, not tenant-verifiable

What the carrier is actually asking

The carrier is asking whether master and privileged credentials, including those used to reach client systems, are held in a purpose-built vault with access control, audit logging, and rotation, rather than in a spreadsheet, a shared note, a documentation platform, or a browser profile.

Why it is underwritten

Credential stores are a primary target. Attackers who reach a service provider look for the documentation platform before anything else, because it converts one compromise into many. For any organisation, a vault turns credential access into a logged, revocable event instead of an invisible one.

Where the answer lives in Microsoft 365, Entra ID, and Azure

Password managers are third-party products that Insurance Posture does not read, so this answer is attested. What the tenant can show is the surrounding posture: who can reach the vault, how they authenticate, and whether credentials are also sitting somewhere they should not be.

PlatformWhere the setting livesWhat has to be true
Password managerThe vault itself: user list, authentication settings, sharing model, audit logMulti-factor on every vault account, shared items scoped to teams rather than to everyone, and an audit trail of retrievals
Entra IDConditional Access covering the vault application, where it federatesVault access is governed by the same policy as other critical applications, ideally with a phishing-resistant factor
Microsoft 365Purview search for credential-shaped content in SharePoint, OneDrive, and mailNo spreadsheets or documents holding administrative passwords alongside the vault
AzureKey Vault usage for application secrets, with rotation policiesApplication credentials are in Key Vault rather than in configuration files, which is the machine half of this question
AnyBreak-glass credential custodyEmergency credentials are held under a documented seal-and-witness process, not only in the vault they might unlock
The vault is not the whole answer

Deploying a password manager and leaving the old credential spreadsheet in place changes nothing. The control is the elimination of the alternatives, and a content search across your collaboration platform is the fastest way to find out whether that happened.

What a defensible yes requires

  • A vault is in use for privileged and client credentials, with multi-factor on every account that can open it.
  • Sharing inside the vault is scoped to the smallest reasonable group rather than organisation-wide.
  • Retrieval is logged, so a compromise can be scoped by which credentials were accessed.
  • The alternatives have been removed, verified by searching your collaboration platform rather than assumed.
  • Application secrets live in a secret store with rotation, not in configuration files or repositories.

How this answer goes wrong

The answer is usually true and incomplete. The vault exists and is used, and the credentials also exist in an onboarding document, a runbook, and a chat message from two years ago. The claim review does not ask whether you have a vault; it asks where the credential that was used came from.

Frequently asked

Does a browser password manager count?

For general user passwords it is better than reuse. For privileged and client credentials it is not, because it lacks the sharing model, retrieval audit, and separation from the workstation that the question is really asking about.

Is a documentation platform with a password field acceptable?

It is common in the service provider market and carriers are increasingly wary of it, because the same platform holds the network diagrams. If you use one, expect follow-up questions about its access control and audit.

What about privileged accounts that no human uses?

Those belong in a secret store with automated rotation rather than in a human vault. Azure Key Vault with a rotation policy is the pattern, and it is measurable.

How do we evidence this?

Vault configuration, the user and multi-factor state, and a sample of the retrieval audit log. Combine it with a content search showing the alternatives are gone.

Related questions

Stop answering this from memory

Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.

Assess your posture