Single Sign-On for Law Firms: SSO, MFA and Access Control
Updated: Oct 9
Single sign-on (SSO) lets staff use their firm’s identity account to access connected SaaS applications instead of maintaining a separate password for each one. For law firms, the useful question is whether that setup makes access easier to manage without weakening control over client and matter information.
What SSO does—and what it does not
An identity provider authenticates a user and passes the result to an application that trusts it. Microsoft Entra ID, Okta and other identity platforms support this kind of sign-in; the applications, protocols and subscription requirements must still be checked individually.
SSO does not automatically decide which matters a person can see. The application’s roles and permissions still control that access. Nor does SSO alone guarantee that an account is created or removed in every connected system.
SSO, MFA and provisioning are different
Control | What it handles | What to check |
SSO | Signing in with an organizational identity | Supported identity provider and sign-in protocol |
MFA | Additional proof of identity | Required factors and recovery procedure |
Provisioning | Creating, updating or disabling application accounts | SCIM or other supported lifecycle integration |
Application permissions | What an authenticated user can do | Roles, matter access and exceptions |
SSO and MFA work together: one simplifies sign-in, while the other adds an identity check. Automatic provisioning is a separate capability. Microsoft’s documentation distinguishes SAML or OIDC sign-in from provisioning accounts into applications.
Joining, changing roles and leaving the firm
When a new employee starts, IT should confirm both the sign-in account and the permissions inside each application. When the person changes roles, review matter access rather than assuming a directory change updates everything.
When someone leaves, disable the identity account, review existing sessions and remove any local or alternate application access. Test the actual offboarding process: stopping a new sign-in is not necessarily the same as ending every active session.
Check which applications allow local passwords to bypass SSO.
Test MFA and account recovery before rolling out to everyone.
Assign responsibility for access reviews and emergency administrator access.
What to ask when evaluating MATTEROOM
Ask the MATTEROOM team to confirm the supported identity provider, licensing, setup requirements and available account-provisioning options for your deployment. Request a demonstration using your firm’s own access scenario rather than assuming every feature of your identity provider is supported.
SSO can support a firm’s access-control and audit processes, but it does not by itself establish compliance with a security standard or legal requirement.
Common questions
Is SSO the same as MFA?
No. SSO connects sign-in across applications; MFA asks for additional proof of identity. A firm can use both.
Does SSO automatically remove a departing employee from every application?
Not necessarily. Provisioning, local accounts and active sessions need separate checks. Test what happens in each connected application.
Does MATTEROOM support our identity provider?
Confirm the provider and your deployment requirements with the MATTEROOM team before planning the rollout.
Comments