Mattermost SSO and identity integration guide

How Mattermost SSO and identity integration works for self-hosted teams

If you run a self-hosted Mattermost server and need staff to sign in through your corporate identity provider without separate passwords, you connect Mattermost to that provider over SAML 2.0, OpenID Connect or OAuth, and you add directory sync if you also want groups and account lifecycle to follow the directory. Single sign-on, group sync and deprovisioning are separate pieces of work, and each one needs its own design decisions and its own tests. Treat them as three workstreams in your plan, not as one checkbox. According to the Mattermost pricing page, SSO (SAML, OIDC, OAuth) and AD/LDAP user sync are included from the Professional plan. Confirm the current plan that includes each feature before you commit budget, because plan contents change between releases and the page is the authority. Your license tier decides whether these options are available at all, so check it before you design anything else. Ask your Mattermost account contact to confirm in writing which plan covers SAML, OIDC, OAuth and AD/LDAP sync for your seat count. The login screen is the easy part. Once a user authenticates, Mattermost has to read the right attributes from the assertion or token, such as email, username, first name and last name, and map them to a Mattermost account. Mismatched attribute names are the most common cause of failed or duplicated logins, especially when an account already exists under a different username. Decide early which attribute is the unique identifier, how you will handle existing local accounts, and whether users may change their own profile fields that the directory is supposed to own. Group logic is the second hard part. If you map directory groups to Mattermost team or channel membership, you need a written rule for who belongs where, how nested groups are flattened, and what happens when a group is removed upstream. Offboarding is the third. A user removed from the identity provider should lose access to Mattermost, and you need to verify that sessions, API tokens and bot accounts do not outlive the person. Test this with a disposable account before go-live, and record who owns each step when a leaver is processed. Before scoping this work, gather the identity provider vendor and version, the protocol you plan to use, the attribute and group schema, and a list of accounts that must be excluded from automated deprovisioning, such as service accounts. Those inputs drive most of the effort, and they should be stated explicitly in any fixed-scope quote.

Which identity paths Mattermost offers and what each one controls

Mattermost separates how users sign in from how their accounts and group memberships are kept current. Each path below governs a different part of that lifecycle, so the choice of paths should follow from which identity source holds the truth for your users.

SAML 2.0 single sign-on

SAML 2.0 handles the sign-in step: users authenticate at your identity provider and Mattermost accepts the assertion. It governs authentication and, depending on the attributes you map, basic profile fields. It does not create group membership on its own or remove accounts when people leave, so deprovisioning needs a separate control. Configure it under the SAML settings in the System Console authentication section and the matching server configuration. Confirm the identity provider is on the officially supported list in the Mattermost SAML single sign-on documentation before you choose a vendor.

OpenID Connect and OAuth sign-in

OpenID Connect and OAuth provide an alternative sign-in path for identity providers that issue OIDC or OAuth tokens rather than SAML assertions. Like SAML, they govern authentication and the profile attributes returned at login. They do not sync group membership or disable accounts for users removed upstream. Configure them in the System Console under the relevant sign-in method, and check the claims your provider sends against the attributes Mattermost expects. Confirm which providers are supported in the Mattermost documentation before selecting one.

AD/LDAP user sync

AD/LDAP user sync reads user records from your directory and keeps Mattermost accounts aligned with them. It governs user attributes such as names and email addresses, and it can reflect account status so that users disabled in the directory stop being active in Mattermost. It does not replace sign-in for every user, and it does not handle group membership unless group sync is also configured. Set it up in the System Console directory synchronization section, and test the filters with a small set of accounts before enabling it broadly.

Group sync

Group sync maps directory or identity provider groups to Mattermost team and channel membership. It governs group membership only, which lets access follow your existing role structure. It does not create accounts, set passwords or determine how users sign in. Map groups deliberately: an overly broad group can grant channel access widely, and a renamed group upstream can silently remove members. Configure group mappings in the System Console group settings and review them after each identity provider change.

Account deprovisioning checks

Deprovisioning is the control that removes or deactivates access when someone leaves or changes role. It depends on which path you use: a sign-in path alone may leave an existing session or account active, while directory sync can deactivate accounts that the directory has disabled. Verify the behavior in a test environment by disabling a test user upstream and confirming access ends in Mattermost. Ask your implementation partner to document the expected result and the time it takes to take effect in your setup.

Choosing between SAML 2.0, OpenID Connect and AD/LDAP sync

This table compares the four identity paths available for Mattermost SSO: SAML 2.0, OpenID Connect, AD/LDAP sync and a combined model. Read each row against your identity provider's capabilities and your team's operating model, because the right path depends on where users and groups are authoritative. Confirm the plan requirement and the group source of truth before go-live, since both change what you build.

Option	When it fits	Operational cost	What it needs from the identity team
SAML 2.0 single sign-on	Your federated identity provider already issues SAML assertions to other applications and you want Mattermost in that same federation	One SAML application per environment to maintain, certificate rotation on the IdP and Mattermost sides, and attribute mapping to review after IdP changes	Metadata exchange, agreed attribute names for email and username, certificate ownership and a rotation calendar, and confirmation that SSO is included in your plan
OpenID Connect sign-in	Your identity provider offers modern OAuth-based sign-in and you prefer token-based flows for the Mattermost login	One client registration per environment, redirect URI management when hostnames change, and secret rotation on a schedule	Client registration with the correct redirect URI, scopes and claims mapped to Mattermost fields, and an owner for client secret rotation
AD/LDAP user and group sync	User lists and group membership live in Active Directory or an LDAP directory and team membership should follow directory groups	Scheduled sync jobs to monitor, service account password rotation, and filter changes when directory structure changes	A bind account with read access, agreed search base and filters, group names to map to teams or channels, and a named owner for the sync schedule
Combined model: SSO for login, LDAP sync for directory	You want login through SAML or OIDC while user records and group membership come from the directory, which is common when the IdP and directory are separate systems	Two integrations to test and two places where a user can be changed, so you need a documented order of operations for account changes	Decisions on which system creates accounts, which system removes access, and how the two identity paths are matched on a shared attribute such as email or username
Plan requirement	Confirm the plan that includes the identity feature you choose before scoping, since SSO and AD/LDAP sync are described as included from the Professional plan	Licensing is an annual subscription based on seats, and no public prices are listed, so cost comes from a sales quote	Ask your Mattermost contact to confirm in writing which plan covers each identity path you select
Source of truth for groups	Required for any option that maps groups to teams or channels, because group membership can be set by the directory, the IdP or by hand in Mattermost	Conflicting group sources cause access drift and manual cleanup after each joiner, mover and leaver event	A written decision before go-live naming the system that owns group membership and who approves changes to group mappings
Deprovisioning path	Applies to every option, since a disabled account in the IdP or directory must also stop Mattermost access	Accounts that remain active after leaving can persist if sign-in and directory sync are not both disabled, so this needs a test each quarter	Documented steps for disabling a user across the IdP, directory and Mattermost, and evidence that a test account loses access

How to configure Mattermost SSO step by step

This sequence takes a Mattermost deployment from an unconfigured server to a tested single sign-on setup with attribute mapping, group sync and team assignment. Each step ends with a check that the team can record, so the pilot starts only when the trust settings and user data are confirmed.

Confirm plan and identity provider support
Start by confirming in writing that your Mattermost plan includes the protocol you intend to use. The pricing page lists SSO (SAML, OIDC, OAuth) and AD/LDAP user sync from the Professional plan, so confirm your edition and ask the vendor whether your identity provider version and protocol are supported. The platform lead and the IdP administrator sign off on one protocol choice, either SAML 2.0, OpenID Connect or AD/LDAP. The output is a short decision record naming the edition, protocol and IdP product. Do not continue until the entitlement is confirmed.
Finalize the site URL and TLS certificate
Set the public site URL and install the production TLS certificate before any identity provider registration. The callback URL and trust settings are built from the hostname, so changing either later breaks the trust relationship and forces you to re-register the application and exchange metadata again. From a test client outside the server, load the site URL over HTTPS and confirm the certificate chain is valid and the hostname matches exactly. Record the final URL in the decision record so the IdP team uses the same value.
Collect IdP metadata and attribute names
Ask the identity provider team for the metadata document or endpoint values, the signing certificate and the exact names of the claims or attributes for email, username, first name, last name and group membership. Record the spelling and capitalization exactly, because mismatched names usually fail silently and leave profile fields empty. Ask for a sample assertion or token from a test account to confirm each attribute is populated. The output is a single configuration worksheet that both teams can review.
Register the Mattermost application at the IdP
The identity provider administrator creates an application for Mattermost, using the callback URL built from the final site URL and the entity or audience identifier defined in the Mattermost SAML documentation for your version. Configure the attribute and group claims collected in the previous step and assign a pilot group to the application. Confirm the exact callback path against the version you are running, because it varies by protocol. Check: an IdP-initiated test sign-in reaches the Mattermost endpoint without an error response.
Configure protocol settings in Mattermost
A platform administrator enters the IdP metadata, signing certificate, login URL and entity identifier in the SSO settings of the System Console, then enables the chosen protocol. Keep a local administrator account with password login available as a recovery path until SSO has been proven end to end. Save the configuration and attempt a sign-in from a browser session that is not logged in. The check is that the sign-in page presents the SSO option and the server log shows no configuration errors on the first attempt.
Map user attributes to profile fields
Map email, username, first name and last name to the attributes recorded in the worksheet. Decide the username rule in advance, including how to handle duplicates and users whose email address changes, because these decisions are hard to reverse once accounts exist. Create a test user in the IdP, sign in with that account and open its user record in the System Console. The check is that each profile field matches the value in the IdP source for that test user.
Set up group sync and team assignment
Configure group sync using either AD/LDAP groups or group claims from the IdP, depending on the protocol and plan confirmed in the first step. Map each IdP group to the Mattermost teams and channels it should populate, and decide what happens when a user leaves a group. The team lead should define default channel membership before the pilot begins. The check is that three test users show the same group memberships in the IdP and in Mattermost, and that removing one test user from a group removes the matching team membership after the next sync.
Test with a pilot group and review logs
Run the pilot with a small group of non-admin users and cover sign-in, sign-out, first login for a new user, a group change and deprovisioning of a disabled account. Ask pilot users to report any unexpected team or channel access. Review the server logs after each scenario for authentication and sync errors, and keep the results in the same worksheet. The pilot is complete when a non-admin test account signs in through SSO, sees only the expected teams, and a deprovisioned test account is blocked, after which the rollout can widen.

What drives SSO integration effort and how to keep it down

This table lists the factors that change how much work a Mattermost SSO and identity integration takes, with the effect of each factor and one way to reduce it. Read each row as a lever you control before the build starts. The main takeaway is that most avoidable effort comes from unsettled group, attribute and environment decisions, so settle those first and ask any partner for a fixed-scope quote that names each driver.

Driver	Effect on effort	How to keep it down
User population size	Larger populations increase sync testing, pilot scope and the number of edge cases in account matching, such as duplicate or renamed accounts.	Start with a pilot group that reflects real account states, then expand in waves after sync results are reviewed.
Number of identity sources	Each additional IdP or directory (for example, a second AD forest or a contractor IdP) needs its own trust, mapping and failure testing.	Confirm the authoritative source for each user type and connect only the sources that own identities Mattermost needs.
Group model complexity	Nested groups, overlapping memberships and groups that map to many teams make sync rules harder to write and verify.	Limit synced groups to those that drive team or channel access, and document which group controls which Mattermost permission.
Custom attribute mapping	Non-standard claims, multi-valued attributes or fields that need transformation add mapping rules and test cases on both sides.	Agree the attribute schema with the IdP team before build, including names, formats and required values.
Number of environments	Test, staging and production each need their own IdP application or configuration, redirect URIs and test accounts, which multiplies setup and review.	Share one IdP application across environments only where security policy allows, and keep environment-specific values in a single documented register.
Multi-team governance	Several owners of groups, claims and approvals slow decisions and can cause rework when one team changes a claim without notice.	Name one owner for the SSO configuration and a change process that covers IdP, Mattermost and group changes together.
Deprovisioning requirements	Requirements such as removing access within a defined window, revoking sessions and reassigning channel ownership add timing tests and process steps.	Write the offboarding expectations down with the identity team and confirm which removal steps Mattermost performs automatically and which need manual action.
IdP team availability	If the identity team is booked for other projects, app registrations, claim changes and test sign-ins wait on their queue, extending the calendar more than the technical work.	Book named IdP staff for the build and test windows before kickoff, and ask any partner to list their dependencies in the quote.

How high availability and air-gapped deployments change SSO setup

On a single Linux server or a single container host, SSO setup is the most direct. One application server handles every login, so the public URL, the redirect address and the identity provider configuration all point at one hostname. Most of the effort goes into the reverse proxy, TLS termination and keeping the SSO settings in one controlled location.

Public URL: Set the site URL to the exact hostname users type, served over TLS through the reverse proxy in front of the server.
Redirect address: Register the SAML assertion consumer service or OIDC callback address with the identity provider using that same hostname and path.
Configuration: Keep SSO settings in one configuration source, and record every change in version control so you can see what changed and when.
Certificates: Name the owner of the TLS certificate and the SAML signing certificate, and record the expiry date of each.

Before you treat the setup as complete, test sign-in, sign-out and a forced session reset from a clean browser, and confirm that a user who is deactivated in the identity provider can no longer sign in.

How to test Mattermost SSO and confirm it fails safely

A Mattermost SSO test plan has to confirm three things before any user depends on single sign-on: legitimate users get the right access, revoked or misconfigured accounts are refused, and administrators can get back in if the identity provider fails. Write the plan as a list of test cases. Each case should name a tester, a test account, the identity provider configuration under test, the Mattermost server version, and an expected result. Run the cases on a staging server connected to a non-production identity provider tenant or realm, so a failed case cannot lock production administrators out.

The happy path covers three checks. First, a new user who signs in for the first time should get an account with the expected username, email address and profile attributes from the identity provider, with no duplicate account created on a second login. Second, a returning user should sign in without a new account being created. Third, a user in a mapped group should receive the expected system role and team or channel membership, and a user outside that group should not. Record which attribute or group claim drives each mapping. An attribute name that does not match the identity provider is the most common cause of a silent failure, so confirm the exact settings against the documentation for your server version.

The negative path is where most of the risk sits. A disabled identity provider account should be refused at the next sign-in attempt. An expired signing certificate or a metadata mismatch should cause sign-in to fail closed, with a clear error in the server logs, and never fall back to a state that admits users without validation. A user removed from the required group should lose access to the team or channel that group granted. Run each case with a named account and a recorded timestamp so the result can be traced later.

Deprovisioning must be tested end to end. Disabling a user in the identity provider should remove Mattermost access within a defined window, and the test should measure from the identity provider change to the first refused request. Include active desktop and mobile sessions, since a session that stays valid after the account is disabled is a gap. The length of that window is a policy decision for your security and HR teams, not something this plan sets, so agree it before the pilot. Confirm in your version which existing sessions survive an identity provider change.

Recovery needs its own tests. Before enforcing SSO for all users, create a break-glass local system administrator account, store its credentials under a controlled process, and confirm it can sign in while the identity provider is unreachable. Document how password login for the user population is re-enabled if the identity provider is down, who may authorize that change, and how to reverse it. Write every expected result before the pilot begins. Sign-off is then objective: a case passes only when the observed result matches the written expectation, and any mismatch is logged as a finding.

Securing SSO secrets, trust settings and admin access

SSO puts Mattermost logins under the control of your identity provider, so the credentials that connect the two and the people who can change them become sensitive assets. The four controls below cover secret handling, admin change control, a tested recovery path and log review, which together keep a configuration problem from becoming a lockout or an unauthorized trust change.

Protect and rotate the IdP secret

The OIDC client secret or the SAML signing and encryption key material must be stored outside the Mattermost configuration files and shared channels, with access limited to the people who run the server. Record where each secret lives, who can read it, and when it was last rotated. Confirm rotation intervals with your security policy and the identity provider vendor, and rehearse a rotation in a staging environment before changing production.

Restrict SSO and group setting changes

Changes to SSO providers, certificates, group mappings and team sync can alter who is able to sign in and what access they receive. Limit console access for these settings to a small named group of system administrators, and require a ticket or change record for each edit. Check the audit trail periodically so that every trust or group change can be matched to an approved request.

Keep a tested local admin path

If the identity provider or its certificate fails, administrators still need a way into the server. Keep at least one local system administrator account with a strong, separately stored credential and confirm that it works before it is needed. Test the recovery path on a schedule and verify that the account's access is limited to recovery tasks and protected by the same monitoring as other privileged accounts.

Review logs for SSO failures

SSO failures often appear first in the Mattermost server logs as rejected assertions, token errors, or failed group sync entries, before users report them. Decide who reviews these logs, how often, and which patterns trigger escalation. Pair the review with identity provider sign-in logs so that a single failure can be traced across both systems.

Assign an owner for certificate expiry

Expired signing certificates and changed identity provider metadata are a common cause of SSO outages, and they often happen without any change on the Mattermost side. Name one owner for certificate expiry dates, metadata updates and the IdP-side configuration, and set reminders well before each expiry. Ask your identity provider vendor how it notifies customers of certificate and metadata changes so the owner receives advance notice.

What to monitor, document and upgrade after SSO goes live

Monitoring after go-live matters most for failures that do not announce themselves. Start by watching failed sign-in attempts for Mattermost, grouped by identity provider and by error type, so a spike caused by an expired SAML certificate or a changed OIDC redirect URI stands out from normal password mistakes. Review sync job results for AD/LDAP or group sync, because a partial sync can leave users with the wrong team or channel access without any visible error in the interface. Compare Mattermost group membership with the groups in your identity provider on a regular schedule, since drift builds up when someone adds a user to a group in one system and forgets the other. Record the expiry dates of the SAML signing certificate, the metadata or OIDC client secret, and any service account passwords used for directory lookups, and set reminders well before each one. Confirm with your Mattermost version which log entries and sync reports it writes, and forward them to the same place your security team already monitors.

The handover package should let someone other than the original implementers keep SSO running. Include the identity provider application configuration, with the entity IDs, redirect URLs, signing certificate locations, and the claims or attributes sent to Mattermost. Add the attribute and group mapping tables that translate directory fields and groups into Mattermost usernames, roles, teams and channels. Document the offboarding procedure step by step, covering how a leaver's identity provider account is disabled, how Mattermost deactivates the matching user, and how sessions and API tokens are revoked. Write the break-glass procedure for the case where the identity provider is unavailable, including who may use a local administrator account, where its credentials are stored, and how each use is logged and reviewed. Name an owner for every item, with a backup owner, and a review date for each. Owners should be roles, not only individuals, so the package survives staff changes.

Upgrades change the ground under SSO, so plan them with the Mattermost release model in view. Mattermost publishes a new server version in binary form on the 16th of each month, which means a monthly decision point for every deployment on the standard track. Extended Support Releases follow a longer cycle, and the current one, v11.7, has support ending on 2027-05-15. Decide which track your organization will follow and who approves each upgrade. Whatever the track, retest SSO configuration after each upgrade you adopt, even when the release notes do not mention authentication. Ask your implementation partner or your own team to confirm which settings the target version reads from configuration files and which it reads from the database, because a change in either can affect how an existing SSO setup behaves after an upgrade.

Before each production upgrade, run a regression check on a staging copy that uses the same identity provider configuration and certificates as production. Test three things in order. First, sign in with test accounts representing each role and each identity provider path, including a user who should be denied access. Second, change group membership in the identity provider and confirm that Mattermost teams, channels and roles update as the mapping tables specify. Third, disable a test account in the identity provider and confirm that Mattermost deactivates it and that its active sessions end. Record the results against the mapping tables, so any difference is visible and traceable. Keep the staging copy current with production configuration, and schedule the check well before the production window so there is time to fix a failure without rushing.

Questions buyers ask before bringing in an SSO partner

How much does a Mattermost SSO integration cost?

The integration cost depends on the scope of the identity work, and the Mattermost subscription is a separate line item. The partner's fee is driven by the protocol (SAML 2.0, OpenID Connect or AD/LDAP), the size of the directory, how groups map to teams and channels, and how many environments need testing, such as staging and production. Mattermost sets its subscription prices through its sales team, and the pricing page does not publish them. Ask for a fixed-scope quote that lists deliverables, assumptions, and which costs are one-time (configuration, group design, testing) and which recur (support, upgrades, plan renewals).

Why do Mattermost SSO quotes vary between partners?

Quotes differ mainly because partners scope the same work in different ways. One proposal may cover only the SSO login flow, while another includes group sync, role mapping, deprovisioning tests and documentation. Directory size, the number of environments, and how many identity providers are involved also change the effort. Some quotes assume your team completes identity provider configuration and test cycles, and others include them. Compare quotes line by line against the same list of deliverables, and ask each partner to state the assumptions behind its estimate. A lower total often means fewer items are included.

How long does a Mattermost SSO and identity integration take?

The schedule depends on three things: how quickly your identity provider administrator grants access, how long group and attribute decisions take, and how many test cycles your security team requires before cutover. No duration is fixed in advance, so ask any partner for a written schedule that shows each milestone, the owner of each step, and what must be ready before the next step starts. Delays usually come from waiting on approvals or from finding attribute mismatches late in testing. Your quote should state the assumed number of test cycles and the dependencies on your side, so both teams can see where time could slip.

What does an SSO project need from our internal team?

Plan for four roles, each with a named person. An identity provider administrator creates the SAML application or OIDC client and releases the claims or attributes Mattermost needs. A directory owner confirms which AD or LDAP groups should map to teams and channels. A security reviewer approves attribute mapping, session length and the deprovisioning test. A test group of pilot users, plus a Mattermost system administrator, checks login, group membership and access removal before production. These people need time in the project plan, because the directory owner and security reviewer are often the slowest to respond.

Can our own team set up Mattermost SSO without a partner?

Yes, if your team already has identity provider administration skills, Mattermost system administration experience, and time to test. The hard part is rarely the first login. It is confirming group sync, role mapping and access removal when someone leaves. Teams that build in house usually need a written test plan, a staging environment and a rollback path before production. Assign one owner on the identity side and one on the Mattermost side, because identity changes affect every user. If those skills or hours are not available, a partner can carry out the build while your team keeps decision rights over attributes, groups and session settings.

Which identity providers does Mattermost officially support for SSO?

Confirm the current list against the Mattermost SAML single sign-on documentation before you choose a provider, because support depends on the protocol and the server version you run. Mattermost documents SAML 2.0 and OpenID Connect for single sign-on, and it supports AD/LDAP for user sync. For any provider you are considering, check three things: whether it supports a documented protocol, whether it can send the username and email attributes Mattermost expects, and whether it can send group claims if you plan to map groups. Ask the provider or partner to demonstrate a working login against your Mattermost version in a test environment.

Does Mattermost SSO require a paid plan?

Yes, according to the Mattermost pricing page, SSO through SAML, OIDC and OAuth, and AD/LDAP user sync are included from the Professional plan. Plans are sold as prepaid annual subscriptions based on seat licenses, and the pricing page lists no public prices, so buyers request a quote from Mattermost sales. Check the current plan table before you commit, because feature placement can change between releases. If your deployment is on a plan below Professional, confirm with the vendor whether SSO and directory sync are available before you scope the work. Ask your partner to confirm the plan in writing, since the plan determines which identity features your server can use.

What happens to access when someone leaves the company?

Access ends only when both the identity provider and Mattermost stop accepting the user, so both sides must be tested. A user disabled in the identity provider may keep an active Mattermost session until that session expires, unless session settings and sync are configured to end it sooner. Verify the full path: disable a test account in the identity provider, confirm the account is deactivated or removed in Mattermost after the sync cycle, and confirm that existing sessions and personal access tokens stop working. Record the times you observe and set a session length that your security reviewer approves. Ask any partner to show this test result, not only a configuration screenshot.

How DeployOpen scopes, builds and hands over Mattermost SSO work

DeployOpen plans, implements, tests, documents and supports Mattermost SSO and identity integration inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Confirm which identity provider you run and whether it is SAML 2.0, OpenID Connect or AD/LDAP.
Confirm the Mattermost plan you hold, since SSO and AD/LDAP sync are listed from the Professional plan.
Record group sync rules, provisioning and deprovisioning owners, and which user populations must sign in.
Agree the written scope, deliverables and timeline before any configuration begins.

How we build

Configure the chosen protocol in a non-production Mattermost instance that matches your deployment method.
Map identity attributes and groups to Mattermost teams and roles, and test each mapping with sample accounts.
Test login, logout, session expiry, account creation and removal against your identity provider.
Verify that deprovisioning removes access as designed, and record the results as test evidence.

How we hand over

Deliver configuration documentation covering the identity provider settings, attribute mappings and group sync rules.
Document the operational runbook for adding identity providers, rotating certificates and secrets, and troubleshooting sign-in.
Walk your administrators through the configuration and the test evidence before the engagement closes.
Record which settings depend on the plan and version you run, so future changes are checked against them.

How we support

Review identity configuration again before each planned Mattermost upgrade, since upgrade testing is part of the work.
Retain support for certificate renewals, provider changes and new group sync rules as a retainer, if you want it.
Re-run the provisioning and deprovisioning tests after changes to the identity provider or Mattermost deployment.
Confirm with your identity team which support responsibilities stay internal and which move to the retainer.

Mattermost SSO and identity integration