Password manager (enterprise) integration security guide: scope every connector, token and service account

An enterprise password manager is only as safe as the connectors around it: the identity provider trust, provisioning tokens, directory sync host, event export keys, ticketing hooks and automation accounts that each reach into the tenant with their own credentials. These integrations are usually set up once during rollout, by one administrator, with whatever scope made the wizard succeed, and then forgotten. Several of them can add users to shared folders, change who can unlock vaults or, in the worst case, read stored credentials. This vendor-neutral guide goes connector by connector: what each integration needs, what it is often given, how to scope, rotate and monitor its credential, and how to test and retire it. It is written for identity engineers and password manager administrators. For hardening the tenant itself (admin roles, recovery, policies) see Securing the password manager (enterprise) itself; this page does not repeat it.

Key takeaways

• Every connector is a non-human identity with a path into the vault. Inventory each one with an owner, a scope, an expiry and a named system it runs on, the same way you would a privileged service account.
• Directory groups become vault permissions. When group sync maps directory or identity provider groups to shared folders, anyone who can change those groups can change who reads team passwords.
• SSO-based unlock moves the key boundary. If vault decryption depends on the identity provider or a key service, those systems become part of the password manager's security perimeter and need tier 0 treatment.
• Reporting tokens should not read secrets. SIEM and reporting integrations need event data only; a token that can also list or decrypt items turns a monitoring feed into an exfiltration path.
• Machine access to human vaults is a design smell. Command-line and API access for scripts belongs in a secrets manager with workload identity, not on a human vault with a long-lived token.

The integration map

Product names differ, but enterprise password managers expose the same kinds of connection. Build this table for your own tenant before changing anything.

The relevant MITRE ATT&CK techniques are T1555.005 Credentials from Password Stores: Password Managers, T1528 Steal Application Access Token for stolen connector tokens, T1098.001 Additional Cloud Credentials for an attacker adding a new API key or client to persist, and T1199 Trusted Relationship where a connected system is the way in.

Identity provider and SSO unlock

Single sign-on is the integration that most changes the password manager's threat model. Sign-in alone hands authentication to the identity provider; SSO-based unlock goes further and lets the identity provider, or a key service it trusts, take part in decrypting the vault.

• Assign by group, not to everyone: restrict the SSO application to a defined group so new or guest identities cannot sign in by default. Monitor that group's membership.
• Enforce MFA at the identity provider for this app: require phishing-resistant MFA through a conditional access or authentication policy targeted at the password manager, not only a tenant default that someone may relax.
• Protect the trust configuration: changes to the SAML signing certificate, OIDC client, redirect URIs or federation settings are tenant takeover events. Alert on them in both the identity provider and the password manager. See the SAML Security Guide.
• Know your unlock model: if the vault still needs a master password after SSO, identity provider compromise gives sign-in but not decryption. If SSO unlock is enabled, identity provider compromise may give both. Record which model you run and treat the identity provider and any key service as tier 0. See Securing the identity provider (IdP) and SSO platform itself.
• Self-hosted key services: run them on dedicated, hardened hosts with restricted admin access, never on shared application servers, and back up their keys under separate custody.
• Trusted-device approval: where new devices are approved by an administrator or an existing device, restrict who can approve and alert on approvals for privileged users.

Provisioning: SCIM and directory connectors

SCIM 2.0 is defined in RFC 7644 (protocol, Proposed Standard). RFC 7644 does not define its own authentication scheme: it relies on TLS and standard HTTP authentication, and allows bearer tokens when combined with TLS and a token framework such as OAuth 2.0. In practice most password manager services issue a single long-lived bearer token that the identity provider stores and presents on every call. Whoever holds that token can create users and change group membership.

• Group-to-folder mapping is access control: a change to a mapped directory group is a change to who can read those shared passwords. Put mapped groups under the same change control and alerting as privileged groups. See the SCIM Provisioning Guide.
• Read-only directory bind: the connector needs to read users and groups, not write them. Use LDAPS or LDAP with StartTLS and a bind account with read rights only. See the LDAP Security Deep Dive Guide.
• Directory integration rules: the NCSC password manager buyers guide says directory integration should let users see only their own credentials, use a well-understood open specification and not interfere with the directory service's other functions.
• Only one source of truth: run either SCIM or a directory connector for a given population, not both, so membership changes have one explainable origin.
• Test deprovisioning: disable a test user in the directory and confirm the password manager account is suspended within the expected sync interval.

Event export, SIEM and reporting

Audit events are the main way to detect misuse of the tenant, so their export needs to be reliable and its credential needs to be harmless if stolen.

• Least scope: create a dedicated API client or key for event collection with read-only access to events, not to users, collections or items. Where the product cannot separate those scopes, record the gap as a risk and restrict where the key can be used.
• Collector placement: run the collector on your log pipeline infrastructure, not on an administrator's workstation, and store the key in a secrets manager. See the SIEM integration security guide.
• Watch for gaps: a collector that stops pulling events is a blind spot. Alert when no events arrive for longer than the normal quiet period.
• Event content: confirm what event records contain. Item names and URLs can be sensitive (they reveal which systems exist and who uses them), so restrict SIEM access to those fields accordingly.

Ticketing, chat and access workflows

• No secrets in tickets or chat: workflows should share access to a vault item or folder, never paste the password into a ticket, chat message or e-mail. The ChatOps Security guide covers chat integrations generally.
• Verify inbound webhooks: where a ticketing system triggers sharing or approvals through a webhook, require signed requests and reject unsigned or replayed calls. See the Webhook Secrets Security Guide.
• Approval is not sharing: the ticket approval should record the decision; the actual grant should be made in the password manager by a role allowed to manage that folder, with expiry where supported.
• OAuth app scope: chat and ticketing apps installed into the password manager, or the password manager's app installed into them, should hold only the scopes needed to post alerts or read request status. See the ServiceNow Integration Users and OAuth Security Guide for a worked example of integration users.

Automation APIs, command-line tools and machine access

Most enterprise password managers offer an administrative API and a command-line client. These are useful for user management and reporting. The risk appears when scripts and pipelines start reading passwords from human vaults.

• Separate admin automation from secret retrieval: an API client that manages users should not be able to read items, and a client that reads items should be limited to one collection.
• Move machine secrets out: application and pipeline credentials belong in a secrets manager that supports workload identity and short-lived credentials. A command-line client logged in with a long-lived token on a build server is a full vault session sitting on shared infrastructure. See the Secrets manager integration security guide.
• Dedicated machine accounts: where a script must use the password manager, give it its own account with access to a single collection, MFA or IP restrictions where the product allows, and an owner. Never reuse an administrator's personal session or API key.
• Verify what you install: pin command-line clients and libraries to known versions, verify checksums or signatures where published, and install from the vendor's official channel. Treat updates to these tools as you would any software supply chain dependency. See the Software Supply Chain Security Guide.

Browser extensions and client deployment

• Deploy centrally: force-install the approved extension through browser or device management, block look-alike or unapproved password manager extensions, and disable the browser's built-in password saving where policy requires one store. See the Browser Extension Security Guide.
• Autofill settings: the NCSC says a password manager should only offer credentials for the site they were saved for and never offer all stored credentials to any site; require a user action to fill as well, so a malicious page or frame cannot harvest credentials silently.
• Update channel: let extensions update from the official store and monitor the installed version across the fleet, so a withdrawn or compromised release can be found quickly.

How to implement: a phased review

1. Inventory: list every integration from the tenant's admin console, the identity provider's app list, the SIEM's collectors and the ticketing system's connections. Record owner, credential type, scope, creation date and host.
2. Rank by blast radius: anything that can unlock vaults or change group membership comes first (SSO unlock, key service, SCIM, directory connector), then admin APIs, then reporting.
3. Re-scope in a test tenant or pilot group: create the new, narrower credential, point a pilot group or a staging connector at it and confirm provisioning, sign-in and event flow still work.
4. Cut over and revoke: switch production to the new credential, then revoke the old one the same day. Rollback is re-pointing to the old credential only during that window; after revocation, roll forward.
5. Add monitoring: alert on new tokens, new API clients, trust configuration changes and collector silence.
6. Recertify: review the inventory each quarter (NHI Mgmt Group recommendation) and on administrator departure, and remove anything without an owner.

Small organisations often have only SSO, SCIM and an event feed: secure those three well and avoid automation access to vaults entirely. Large organisations usually have several directories, regional tenants and many scripts; they need an integration register, a change process for mapped groups and a plan to move machine secrets to a secrets manager.

Detection and measurement

Metrics:

• Integrations with a named owner, scope and expiry, as a percentage of all integrations.
• Age of the oldest SCIM token and API key.
• Automation accounts with item read access, falling towards zero.
• Time from directory disablement to password manager suspension.
• Alerts on mapped-group changes reviewed within one working day.

Framework mapping

Common failure patterns

• The SCIM token in a shared note: the provisioning token was copied into a vault item or wiki during setup, never rotated and readable by several administrators.
• Everyone assigned to SSO: the SSO application is available to all directory users, including guests and contractors who should not have vaults.
• Unwatched mapped groups: a help-desk role that can edit directory groups can silently grant itself the infrastructure team's shared folder.
• A reporting key with admin scope: the SIEM collector uses an all-powerful API key because it was the only one the setup guide described.
• Pipelines reading human vaults: build servers run a logged-in command-line session tied to an engineer's account.
• Connector on a shared server: the directory connector runs on a general application server under an administrator's account, so any compromise of that server reaches the tenant.

Practitioner checklist

• Build an integration register with owner, credential, scope, host and expiry for every connector.
• Restrict the SSO application to a defined group and enforce phishing-resistant MFA for it at the identity provider.
• Document whether SSO unlock is enabled and treat the identity provider and key service as tier 0 if it is.
• Rotate SCIM tokens on a schedule and on administrator departure, and alert on token generation.
• Run directory connectors on dedicated hosts with read-only LDAPS binds.
• Put directory groups mapped to vault folders under change control and alerting.
• Give SIEM collectors event-only credentials and alert on collector silence.
• Remove machine access to human vaults and move those secrets to a secrets manager.
• Deploy extensions and clients centrally from official channels and track versions.

Standards and references

• NCSC: Password manager buyers guide
• IETF: RFC 7644 System for Cross-domain Identity Management: Protocol
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Credentials from Password Stores: Password Managers
• MITRE ATT&CK: Steal Application Access Token
• OWASP: Secrets Management Cheat Sheet

Related NHI Mgmt Group resources: Password manager (enterprise) health check · Password Manager Buyer's Guide · Service Account Security Guide · Identity provider (IdP) and SSO platform integration security guide