SAML vs. SCIM for Password Managers: What MSPs Need for Client Deployment

SAML handles authentication, and SCIM handles user lifecycle. When we work with MSPs deploying Armory to their clients, we find they almost always need both — centralized sign-in plus automated provisioning and offboarding — but the reasons why are worth understanding before you configure anything.

That distinction matters during a password-manager rollout because authentication and account administration solve fundamentally different problems, and conflating them is where most deployment mistakes begin.

SAML lets a user's corporate identity provider establish who they are when they sign in. SCIM creates, updates, disables, or otherwise manages the corresponding account as directory state changes. Neither protocol, by itself, defines how an encrypted password vault gets decrypted, how vault permissions should be structured, or how every third-party SaaS session should be terminated when an employee leaves.

For MSPs, the deployment question is therefore not simply “Does the password manager support SSO?” It is a set of operational questions that determine how much of the lifecycle you can actually automate:

• Who creates and removes users?
• What directory or identity provider is authoritative?
• What happens when a user changes roles?
• What must occur when employment ends?
• Which actions are automated, and which remain manual procedures?
• Does centralized authentication stay separate from the keys that protect encrypted vault data?

We support SAML and SCIM in Armory for business deployments, and we publicly document both. But the practical value of those capabilities depends entirely on how they are incorporated into the client's identity, vault-access, and offboarding processes — the protocol support is just the starting point.

What SAML does in a password-manager deployment

SAML 2.0 is an XML-based federation standard used to exchange authentication and identity information between an identity provider (IdP) and a service provider (SP). In the common browser SSO flow, the password manager acts as the service provider and a corporate identity system authenticates the user.

The OASIS SAML 2.0 technical overview describes SAML assertions as carrying statements about a principal, including authentication and attribute information.

For a password-manager deployment, SAML primarily changes how users authenticate to the service. Instead of maintaining a separate enterprise sign-in path, the organization routes authentication through its identity provider, which gives IT a centralized place to apply identity controls like authentication policies and account state.

SAML does not inherently:

• create the password-manager account before first use;
• remove the account when a user leaves;
• synchronize group membership continuously;
• decide which vaults an employee may access;
• erase active sessions at unrelated SaaS providers; or
• supply the cryptographic secret required to decrypt a client-side encrypted vault, unless a product explicitly implements such a design.

That last point is particularly important for password managers, and it is something we take seriously in our architecture. Authentication and vault decryption are separate security functions. Our security architecture uses client-side encryption — our servers store encrypted data, never plaintext vault contents. Identifying a user through an enterprise sign-in flow is not the same thing as giving the identity provider plaintext access to the vault, and that boundary is deliberate.

For MSPs, treat SAML as an authentication-control plane, not as the complete lifecycle mechanism.

What SCIM does in a password-manager deployment

SCIM, the System for Cross-domain Identity Management, addresses a different problem entirely: moving identity lifecycle information between systems.

RFC 7643 defines a common schema for resources such as users and groups, and RFC 7644 defines an HTTP-based protocol for provisioning and managing those identity resources.

Operationally, SCIM allows a client's directory or identity platform to communicate changes such as:

• create this user;
• update this user's attributes;
• change this user's group state; or
• deactivate this user.

The exact behavior depends on what the identity provider and password manager both implement. We encourage MSPs to test supported attributes, group behavior, deactivation semantics, synchronization timing, and error handling rather than assuming every SCIM implementation behaves identically — ours included.

That makes SCIM especially useful during onboarding and offboarding. Without lifecycle automation, your technicians have to create and remove accounts manually in each application, which becomes unsustainable as client organizations grow. With a properly configured SCIM workflow, directory changes become the trigger for corresponding changes in the password manager.

SCIM still does not replace vault authorization design. A user existing in the application does not automatically mean the user should receive every shared credential — that is a separate access-control decision that the MSP needs to make deliberately.

SAML vs. SCIM comparison table

When an MSP needs SAML only, SCIM only, both, or neither

The right configuration depends on the client's identity architecture rather than company size alone. We have seen ten-person firms that genuinely need both protocols and fifty-person organizations where neither makes sense yet.

Deployment decision table

SAML only

Choose SAML without SCIM when centralized authentication is required but account changes are intentionally managed inside the password manager. That can work for a small or unusually stable organization, and we see it fairly often with clients under twenty users. The tradeoff is operational: onboarding and offboarding remain technician tasks, so you need a reliable ticketing and access-review process to make sure nothing falls through the cracks.

SCIM only

SCIM without SAML can make sense when the client primarily wants the directory to control account creation and deactivation while retaining the application's existing authentication method. This is less common in SSO-centric enterprises but is technically coherent — provisioning and authentication genuinely are separate concerns, and there is no requirement that they use the same protocol.

Both

For many directory-centric organizations, using both is the cleanest model and the one we recommend as a default starting point for MSP password-manager deployments. SAML centralizes the authentication path while SCIM connects user lifecycle to the directory, and the two protocols complement rather than replace one another.

Neither

Not every SMB needs federation infrastructure, and we would rather you skip it than bolt it on prematurely. For a small team with infrequent staffing changes, manual onboarding and offboarding can be entirely reasonable if it is documented, assigned to an owner, and tested. Avoid adding identity infrastructure solely to check a feature box — the operational overhead of misconfigured SAML or SCIM is worse than thoughtful manual administration.

A practical rollout sequence for a new client

A successful rollout starts with identity and authorization design before browser extensions reach employee devices. We have published a comprehensive MSP password-manager deployment guide that covers the broader process, but the protocol-specific sequence should look roughly like this:

1. Establish the identity source of truth. Determine whether HR, Microsoft Entra, another IdP, or a manual administrative process controls workforce identity for this client.
2. Define user scope. Identify which employees, contractors, service accounts, and administrators should receive password-manager accounts — and which should not.
3. Design vault boundaries. Map departments and operational roles to the credentials they actually need. Do not use directory membership as a substitute for deliberate vault authorization; a group in Entra is not the same thing as a vault-access policy.
4. Configure lifecycle behavior. If SCIM is used, determine which groups or assignments trigger provisioning and what deactivation should do in practice.
5. Configure SAML. Establish federation, identifiers, certificates or metadata, and the expected sign-in path.
6. Pilot with a small representative group. Include a normal employee, an administrator, and at least one user whose role resembles a common client workflow.
7. Test lifecycle events. Create, modify, disable, and — where appropriate — re-enable a test identity through the full directory-to-password-manager chain.
8. Deploy endpoints and train users. Only after identity flows are predictable should you broaden rollout to the full organization.
9. Document break-glass procedures. Know how administrators recover access when the IdP, federation configuration, or user assignment is unavailable.
10. Run an offboarding simulation. The deployment is not complete until the team has proved it can remove access entirely — use our employee offboarding checklist to make sure nothing is missed.

The goal is repeatability. A protocol integration is only operationally useful when its failure modes are understood and support staff know which system is authoritative at each step.

Microsoft Entra deployment considerations

Microsoft Entra deployments introduce several layers that technicians should keep distinct: the Entra user, enterprise-application assignment, SAML federation configuration, provisioning configuration, application account, vault permissions, and existing browser or SaaS sessions. Each layer can be correct on its own and still produce a broken deployment when the interactions between them are not tested.

We have published a dedicated Microsoft Entra deployment guide that covers the specific configuration steps. Use that guide when building the client configuration rather than treating a successful SSO login as proof that provisioning is correct.

In particular, validate:

• the identifier used to match an Entra identity to its Armory account;
• which users or groups are assigned to the enterprise application;
• which attributes are actually synchronized via SCIM;
• what happens when a user is unassigned from the application;
• what happens when the Entra account is disabled;
• how quickly provisioning changes propagate;
• whether reactivation behaves as expected; and
• how administrators regain access if the federation path is unavailable.

Do not make a production cutover after testing only a successful login. Login is the SAML test. Creation, update, deactivation, and assignment changes are the lifecycle tests, and they are the ones that matter most when something goes wrong six months after deployment.

Offboarding: directory disablement is only the first layer

Offboarding is where the distinction between authentication, provisioning, vault authorization, and session state becomes most consequential. A thorough employee offboarding security process should address four separate controls, and skipping any one of them leaves a gap.

1. Disable the directory identity

Start with the client's authoritative identity system according to the organization's termination procedure. This prevents the directory identity from continuing to authenticate where that control applies and can trigger downstream provisioning changes through SCIM.

Do not assume that disabling a directory user instantly removes every session everywhere — that assumption is the single most common offboarding mistake we see.

2. Revoke Armory sessions

Our Nuke Sessions capability is designed as a browser-containment action. It revokes active Armory sessions and instructs connected authenticated extensions to clear website cookies, site storage, cached credentials, and keys, then reload open tabs.

We describe this explicitly as one containment step rather than a replacement for account disablement, provider-side revocation, endpoint investigation, or credential rotation. That distinction should be preserved in the MSP runbook — Nuke Sessions is powerful, but it operates within the browser environment and does not reach sessions that were established outside of it.

3. Remove vault access

A disabled account should no longer retain access to organizational vault material. Review shared vault memberships, administrative roles, recovery roles, and any access inherited from group or organizational structures. Where credentials were known or usable by the departing employee, determine whether rotation is necessary — and in a security-sensitive departure, default to rotating.

Provisioning status and vault authorization should be checked independently, because SCIM deactivation and vault-access removal are not always the same operation.

4. Follow up on third-party sessions

An employee may already have authenticated sessions with email, storage, finance, social media, development tools, or other SaaS services that persist independently of anything the password manager controls.

SAML and SCIM do not provide a universal “log this person out of every website” mechanism. Provider-side token revocation, account disablement, session termination, password rotation, and endpoint actions can still be required for each service. We publish an employee offboarding checklist specifically to help MSPs track these follow-up actions systematically rather than relying on a single deprovisioning event to do all the work.

How WebAuthn passkeys fit after SAML sign-in

Passkeys and SAML operate at different layers and can coexist comfortably, which is something we get asked about frequently.

WebAuthn is a public-key authentication standard. A passkey allows an application to authenticate a user through a cryptographic credential associated with the relying party, which means the user never transmits a reusable password. SAML, meanwhile, federates an authentication result between an identity provider and a service provider.

An organization can therefore use SAML as the enterprise entry point while also using passkey-based authentication in appropriate application flows. We built Open Passkey on WebAuthn specifically to provide tooling for implementing passkey authentication, and we use it in our own products.

The important design principle — and this applies to every password manager, not just ours — is that authentication should not silently collapse into vault decryption. Our security architecture keeps vault encryption and decryption client-side. A SAML assertion or successful WebAuthn ceremony establishes that an identity has authenticated, but that is conceptually distinct from making plaintext vault contents available.

For MSPs evaluating any password manager, we recommend asking vendors to explain this boundary explicitly:

• What does SSO authenticate?
• What cryptographic material unlocks the vault?
• Where does decryption occur?
• Can the service provider or IdP decrypt vault contents?
• What happens to encryption keys when an administrator disables a user?

Those questions are more useful than treating “passwordless” as a blanket security property, and the answers will tell you more about a vendor's architecture than any feature checklist.

Common configuration mistakes and pre-launch tests

Most deployment failures are not protocol failures. They are mismatches between assumptions, and after working with MSPs across a range of client sizes, the same patterns come up repeatedly.

Common mistakes include using different identifiers for SAML and SCIM (so the system creates a second account instead of linking to the one that already exists), provisioning an overly broad directory group that gives every employee access to every vault, assuming a disabled directory identity has already lost every application session, and failing to test what happens when a user changes departments.

Another frequent problem is collapsing account existence and authorization into one concept. SCIM helps determine whether a user exists in an application, but the MSP still needs to define which vaults that user should actually access — existence and authorization are separate decisions.

Pre-launch checklist

• Identify the authoritative directory or identity source.
• Document whether SAML, SCIM, both, or neither are required for this client.
• Confirm the unique user identifier used across systems.
• Limit initial application assignment to the pilot population.
• Test a new-user provisioning event.
• Test an attribute or group change.
• Test a disabled or unassigned user.
• Verify expected vault-access removal separately from directory deactivation.
• Test SAML sign-in from a clean browser session.
• Confirm the administrator break-glass procedure.
• Test behavior when the identity provider is unavailable.
• Document SCIM synchronization errors and where technicians will see them.
• Test session revocation as part of an offboarding simulation.
• Identify third-party applications requiring separate session revocation.
• Record who owns credential rotation after an employee departure.
• Obtain client approval before moving from pilot to organization-wide deployment.

FAQ

Conclusion

The useful way to evaluate SAML and SCIM is not as competing checkboxes on a feature comparison — it is as complementary layers that each solve a specific problem.

SAML centralizes an authentication path. SCIM connects account lifecycle to a directory. Vault authorization determines which secrets an employee may use. Client-side cryptography determines who can decrypt vault data. Session-revocation and credential-rotation procedures determine what happens after access should end.

For MSPs, deployment quality comes from connecting those layers deliberately, without assuming that one protocol handles the responsibilities of the others.

Before rolling out a password manager for MSPs to an entire client, prove the lifecycle with a pilot account: provision it, authenticate it, change its access, disable it, revoke its sessions, remove its vault permissions, and verify the remaining third-party cleanup steps. That test exposes more operational risk than a successful SSO screenshot ever will.