Why Mautic SSO needs a deliberate design before configuration
Your security or IT team has been asked to put Mautic users behind the corporate identity provider, such as Microsoft Entra ID, so that marketing staff sign in with the same credentials and access is removed centrally when someone leaves. Mautic SSO is SAML-based, and the identity provider must send an email address, a first name and a last name for each user. Those three attributes are the minimum the integration depends on, so confirm with your identity team that they can be released by the provider and mapped correctly before any Mautic work starts.
The reason this needs design is that Mautic does not work like an application that inherits your directory. Its users are managed with basic authentication inside Mautic, and the authentication documentation describes a SAML single sign-on option but no LDAP option. That means there is no directory lookup to fall back on, and the identity provider does not automatically define who can use Mautic or what they can do once inside. Decide in advance which accounts stay local, which accounts must be federated, and whether any service or integration accounts need to keep working when the identity provider is unavailable.
User lifecycle and role assignment are separate decisions from the SAML connection itself. You need to define how a new employee gets an account, which default role a created user receives, who may promote a user to an administrator role, and how an account is disabled when someone changes teams or leaves. Map these to your joiner, mover and leaver process and to the group claims your identity provider can send. Without this mapping, users may sign in successfully yet hold permissions that nobody approved, or lose access they need for campaigns.
Certificate handling and administrator recovery also need explicit owners. The SAML signing certificate has an expiry date, and when it rotates, Mautic must be updated or sign-in stops for everyone. Name the team that tracks certificate expiry, the procedure for replacing it, and the test that proves the change worked. Equally important, confirm how an administrator regains access if the identity provider configuration is wrong or the tenant is unavailable. A documented local recovery path, held by a named person and tested before go-live, is what prevents a sign-in fault from becoming a lockout.
This topic covers the integration itself: the SAML connection, attribute mapping, default roles, certificates, recovery and the limits of Mautic's built-in authentication. It does not cover installing Mautic, sizing servers or configuring the wider platform, which are handled in the implementation and security topics. Before you commit to a design, ask your implementation partner or internal team to document each of these decisions in writing, because the configuration steps are short once those decisions are settled.
Which parts of the identity chain Mautic depends on
Single sign-on for Mautic depends on six components that must match: the identity provider application, Mautic's SAML settings, the attributes sent in each assertion, Mautic's user records and roles, the signing certificate, and a local recovery account. A change in one usually breaks the others, so assign each an owner and review them together. Confirm configuration keys against the authentication documentation for the Mautic release in use.
Identity provider application
The enterprise application registered in the identity provider, such as Entra ID, that issues SAML assertions for Mautic. It controls user and group assignment, the single sign-on method, and the entity identifier and assertion consumer endpoint that Mautic must match exactly. Identity administrators usually own it. The Mautic owner should review every change to these values before go-live. Confirm the exact endpoint values against the Mautic authentication documentation for the release in use.
Mautic SAML configuration and metadata
The service provider settings on the Mautic side, including the entity identifier, login and logout endpoints, and the metadata Mautic expects from the identity provider. Any mismatch with the identity provider application produces failed logins that can look like access problems. The Mautic administrator or platform engineer typically owns this. Keep the settings in version-controlled configuration so changes are traceable, and confirm the configuration keys for the release in use before editing.
User attributes in assertions
The claims the identity provider sends with each login. Mautic's authentication documentation states that the SAML provider must send email, first name and last name. Map these from directory fields such as the mail or user principal name attribute, then test with accounts from each group. Missing or renamed claims can create duplicate users or accounts that cannot be used. Identity administrators own the claim rules, and the Mautic owner confirms what Mautic receives.
Mautic user records and roles
The local user accounts Mautic creates or updates after a successful login, along with the role each one receives. Roles decide which contacts, campaigns, emails and settings a person can reach, so a default role that is too broad grants access to everyone who can sign in. Decide the default role for created users, how it changes, and who approves elevated roles. The Mautic administrator owns these records, working with the business owner of each area.
Signing certificate
The certificate the identity provider uses to sign assertions, which Mautic trusts to verify each login. Record its expiry date, the person who renews it, and the step where the replacement is loaded on both sides. An expired or unexpectedly replaced certificate stops single sign-on logins for every user at once. Identity administrators usually own renewal, and the Mautic owner must confirm the trusted copy is updated before the old certificate expires.
Local administrator account
A Mautic user with a local password that does not depend on the identity provider. It gives the team a way to sign in and repair the SAML configuration when the identity provider, certificate or network path fails. Store its credentials in the organization's approved secrets system, limit who knows them, test the login on a schedule, and log each use. Mautic's built-in authentication is basic, so this account serves as a recovery path only.
Decisions to settle before configuring SAML in Mautic
This table compares the main identity decisions for Mautic SAML single sign-on and the operational cost of each option. Read each row as a choice to make before configuration, and note the cost column, which shows what your team will maintain after launch. The main takeaway is that Mautic's role assignment and admin access need a deliberate plan, because the documented authentication options do not replace a local admin path.
| Decision | When the option fits | Operational cost to plan for |
|---|---|---|
| SAML SSO alongside basic login or SSO only | Alongside basic login fits a pilot, a small admin group, or a period when the identity provider is still being tested. SSO only fits when every user must authenticate through the corporate identity provider and you have confirmed a working admin fallback. | Keeping basic login means separate passwords to manage and review. SSO only puts every sign-in, including emergency access, on the identity provider's availability. Confirm with the Mautic docs for your version whether both methods can run together before you decide. |
| Entra ID or another SAML provider | Entra ID fits organizations already running Microsoft identity for staff accounts. Another SAML provider fits where that provider is the system of record for workforce identity. | Each provider has its own app registration, claim configuration and certificate lifecycle. Confirm which attributes the provider can send (email, first name, last name) in the format Mautic expects, since the docs require these three attributes. |
| Create users on first login or pre-provision them | First login creation fits teams with many occasional users and low admin overhead. Pre-provisioning fits teams that need named accounts and roles approved before anyone signs in. | First login creation can leave accounts with default roles until an admin adjusts them. Pre-provisioning adds an admin step for each new user and a sync process to keep accounts current. Confirm what default role a first-login user receives in your version. |
| Assign Mautic roles manually or from identity provider groups | Manual assignment fits small teams with few roles and infrequent changes. Group-based assignment fits larger teams where access follows directory group membership. | Manual roles need ongoing review when people move teams. Group-based roles depend on assertions that Mautic must accept. Confirm with the Mautic docs and a test login whether any group attribute maps to a Mautic role. Do not assume a mapping exists. |
| Deprovisioning and offboarding | Any SSO setup where former staff must lose access promptly, which is most regulated environments. | Disabling a directory account blocks SSO sign-in, but a Mautic user record can remain active for a local login or API use. Define who disables Mautic accounts, how often orphaned users are reviewed, and how API credentials are revoked. |
| Keeping a local break-glass admin | Almost every production install, so admin access survives an identity provider outage, a misconfigured certificate or a lockout. | The account must be stored securely, tested on a schedule and excluded from routine SSO-only enforcement. It creates a password to manage and a path that attackers may target, so restrict its use and monitor logins. Confirm your version's supported local login behavior before relying on it. |
How to configure Mautic SAML SSO with Entra ID, step by step
This sequence takes a Mautic installation from a confirmed release and its documented SAML requirements to SSO for all users through Entra ID. Each step closes with a check, such as a test login that creates a user with the correct name and email fields. The local administrator account stays active throughout, so a failed configuration does not lock the team out of the platform.
Confirm the Mautic release and authentication docs
Record the exact Mautic release you run, then read the authentication documentation for that release before changing any settings. The docs cover basic authentication and the SAML identity provider option, and they state that the identity provider must send email, first name and last name attributes. Confirm the PHP version and support dates for your release, because Mautic 7.2 receives support through 30 September 2026 and Mautic 7.3 is planned as the long-term support release. This step is done when the team holds a written note of the release, the SAML fields the docs expect, and the required attribute list.
Create the Entra ID enterprise application
In the Microsoft Entra admin center, create an enterprise application for Mautic, using a non-gallery SAML application if your tenant policy requires it. Take the entity identifier and reply URL values from the Mautic SAML configuration, which are built from your public Mautic hostname, and enter them exactly as your release documents specify, including the scheme and any path. Confirm the hostname matches the DNS record and certificate planned for production. Check: the SAML setup page in Entra ID shows both saved values, and each one matches what Mautic displays character for character.
Configure claims for email and name
Open the attributes and claims section for the application and map the email, given name and surname claims that Mautic requires. Entra ID often emits claims under long schema URIs, so map them to the attribute names your Mautic release expects and confirm those names in the docs. Agree with the identity team which directory field supplies email, since a mismatch between the sign-in name and the mail address can create duplicate or unmatched Mautic accounts. Check: a SAML response captured with a browser SAML tracing tool for a test user shows all three values populated.
Exchange metadata and load identity provider settings
Download the federation metadata or the signing certificate, along with the sign-in and sign-out URLs, from the Entra ID application. Load these into the Mautic SAML identity provider settings, and confirm the service provider entity identifier in Mautic matches the value in Entra ID. Record the certificate expiry date in your certificate register, because Entra ID signing certificates have their own renewal schedule and an expired certificate stops sign-in. Check: the SSO option appears on the Mautic login page as your release documents describe, and a test sign-in travels to Entra ID and returns to Mautic without a certificate or signature error.
Set default roles for first-login users
Confirm whether your Mautic release creates a user record on first SAML sign-in and, if it does, which role that new user receives. Create or confirm a least-privilege role for these users, and keep administrator permissions out of the default assignment. Document who approves any role change after first sign-in, so access does not drift over time. Check: review the role assignment and the user list, then sign in as a newly created test account and attempt an administrator-only page. The check passes when the account carries the intended role and is denied the admin action.
Test with a pilot account
Assign one pilot user to the Entra ID application and keep the local Mautic administrator account enabled, with a tested password and a written recovery procedure. Sign in as the pilot user and confirm the Mautic account is created with the correct first name, last name and email address, and that its role matches the role set in the previous step. Sign out, confirm the local administrator still signs in, and test an unassigned directory user to confirm access is refused. Check: the pilot record matches the Entra ID profile field for field, and both successful sign-ins work.
Enable SSO for all users
Only after the pilot checks pass, assign the intended user groups to the Entra ID application and extend access to them. Record the change, tell users about the new sign-in path, and keep the local administrator as break-glass access. Confirm with the identity team how offboarding works, because a disabled Entra ID account blocks SSO sign-in, but the Mautic user record and its permissions may remain until an administrator changes them under your documented process. Check: a sample of production users signs in through SSO, and an offboarding test shows the disabled user is blocked and their Mautic record is handled as the process states.
Which user attributes Mautic needs and how certificates affect logins
The identity provider must send three attributes in every SAML assertion Mautic receives: email address, first name and last name. Mautic's authentication documentation names these as the required attributes for its SAML single sign-on integration, and the documentation describes no LDAP option, so the directory and the assertion are the only source of identity data. Before any user signs in, confirm in the provider's console that each attribute is populated for every person who needs access, and that the claim names in the assertion match the names you have mapped in Mautic. Service accounts, shared mailboxes and guest accounts often lack a first or last name, so decide now whether they should have Mautic access at all.
Mismatches usually surface as failed or confusing logins rather than clear errors. A missing email attribute means Mautic cannot match the sign-in to a user record. A first or last name mapped to the wrong claim produces users whose names look wrong in audit fields and user lists, which matters when you later review who changed a campaign or a segment. Formatting differences also cause trouble: an email stored in mixed case in the directory and lower case in the assertion, or a name carried as a combined display name in one place and split fields in another. Test with at least one account per role and compare the raw assertion against the Mautic user record before you widen access. Ask your integration partner or internal team to document each claim name, its source field in the directory, and any transformation applied.
The signing certificate and the identity provider metadata are the two artifacts Mautic depends on. The metadata describes the provider's endpoints and carries the public certificate used to verify assertions, and it should be downloaded from the provider's federation metadata location for the specific application, not copied from a previous environment. Record the certificate's expiry date and the owner of the renewal in your change calendar. The lifetimes and default rotation behavior of Entra ID signing certificates are set by Microsoft and change over time, so check the current Microsoft Entra documentation for your tenant before you set any reminder. Assume that a certificate can expire on a date that does not coincide with your release cycle, and assign one named owner to track it, with a second person who can act if that owner is unavailable.
A rotation is safest when the new certificate is staged alongside the old one. Where the provider supports publishing more than one signing certificate, add the new one to the trust configuration in Mautic and verify a test sign-in before the provider switches its active certificate. Keep the old certificate valid until all active sessions have ended and the cutover is confirmed. Plan the change in a low-traffic window, have a rollback path that restores the previous metadata, and confirm that local administrator access still works so that a misconfiguration does not lock out everyone. Confirm with the vendor how Mautic in your version handles multiple certificates or metadata refresh before relying on that sequence.
Private key material must never be stored in Mautic's configuration files, in the repository that holds your deployment code, in shared tickets, or in chat. The identity provider only needs the public certificate and the Mautic service provider settings. If your configuration process requires a private key for any reason, keep it in your organization's secrets manager or hardware-backed store with access logging, and restrict who can read it. Review your deployment templates and backups for accidental copies, because a database or configuration backup that contains key material is as sensitive as the key itself. Ask your security team to confirm the storage location in writing as part of the go-live checklist.
What drives the effort and cost of Mautic SSO work
This table lists the main factors that change how much work Mautic SSO and identity integration takes, who typically carries each one, and how to keep it down. Read each row as a question to answer before requesting a quote, since most of these drivers multiply across environments and identity providers. The main takeaway is that environment count, role mapping and identity provider count usually matter more than the SAML setup itself.
| Driver | Why it changes effort | Who pays for it | How to keep it down |
|---|---|---|---|
| Number of Mautic environments | Production, staging and development each need their own service provider configuration, callback URLs, certificates and testing | Partner on a fixed-scope quote for setup, internal staff for ongoing environment changes | Limit SSO to the environments that hold real contact data and reuse one tested configuration pattern |
| User population and joiner-mover-leaver volume | Frequent provisioning, role changes and removals increase the number of login and access checks to verify and document | Identity administrators for lifecycle processes, internal staff for user review | Drive access from identity groups so changes happen once in the identity provider |
| Complexity of the role model | Each Mautic role that must come from identity groups needs a mapping rule and test cases for every combination | Partner for mapping design, internal business owners for approving role scope | Keep the number of Mautic roles small and agree the mapping table before build starts |
| Number of identity providers or tenants | Each provider or tenant adds its own metadata, attribute release rules, certificates and test accounts | Identity administrators per tenant, partner for integration work per provider | Confirm early whether one tenant is enough and avoid per-team identity sources |
| Custom authentication beyond built-in SAML | Mautic's documented options are basic authentication and SAML, so anything else needs custom code, a bridge or a process decision that must be tested and maintained | Partner for scoped custom work, internal staff for ongoing ownership of custom code | Confirm the requirement with the vendor and your security team before scoping, and prefer SAML where it meets policy |
| Audit and compliance evidence requests | Assessors may ask for configuration exports, access reviews, certificate records and change history, which need to be collected and kept current | Internal compliance staff for evidence ownership, partner for documenting configuration and test results | Agree the evidence list in the scope and collect it as part of build and handover, not later |
How the SSO design changes by deployment model
On a single node, the web application, cron jobs and any queue consumer run on the same server, so the SAML service provider settings are defined once and apply everywhere. The entity identifier and assertion consumer URL only need to match the public hostname that users reach. Session state lives on one machine, which keeps the design simple, but a hostname change or certificate rotation affects the whole installation at once.
- Entity identifier and assertion consumer URL: Set once against the public hostname. Confirm that the values in the identity provider match Mautic's configuration exactly, including scheme, host and path.
- Sessions: Held on the single host, so sticky sessions are not required. Confirm where Mautic stores session data in the release you deploy.
- Cron and background jobs: Segment, campaign and broadcast commands run on the same host under a designated admin context. Confirm how these commands authenticate and that they do not depend on an interactive SSO login.
- Metadata and certificates: Import the identity provider metadata once, then record the certificate and its expiry date in your change log so rotation is scheduled before it lapses.
Before go-live, check the hostname, the admin context used by cron and the certificate expiry date against the Mautic release documentation and your own identity provider settings.
With several web nodes behind a load balancer, every node must present the same service provider identity and accept the same assertion consumer endpoint. The SAML response must be processed correctly regardless of which node receives it. Session handling, cron scheduling and certificate distribution all need explicit design, because a mismatch on any one node can produce intermittent login failures that are hard to trace.
- Entity identifier and assertion consumer URL: Identical on every node and bound to the load balancer's public name, so the identity provider sees one consistent service provider.
- Sessions: Decide between shared session storage and sticky sessions. Confirm which approach the Mautic release supports and how the login redirect behaves when the browser returns to a different node.
- Cron and background jobs: Schedule segment, campaign and broadcast commands from one designated node or scheduler so jobs do not run twice. Mautic's cron documentation recommends staggering these jobs, and the same schedule must be verified after any node change.
- Certificates: Deploy the same signing certificate to every node and keep a rotation runbook that updates all nodes in one controlled change.
- Clock synchronization: SAML assertions carry validity windows, so drift between nodes or with the identity provider can reject valid logins. Confirm the tolerance your identity provider applies.
Before go-live, test login through each node individually and through the load balancer, and confirm that cron output appears once per scheduled run.
When the identity provider cannot be reached from the Mautic network, the metadata exchange cannot be a live fetch. Metadata, certificates and any updates must move through a controlled process, and users can sign in only if their browsers can reach both the identity provider and Mautic. The design therefore starts with network routing and ends with a documented recovery path for when the identity provider is unavailable.
- Metadata delivery: Export the metadata XML from the identity provider and transfer it through approved media or an internal file share. Verify its checksum with the sender before import.
- Network path: Confirm DNS resolution and routing for both the Mautic hostname and the identity provider endpoints from the user networks, not only from the server.
- Certificate rotation: Plan the transfer of new metadata well before the current certificate expires, because there is no automatic refresh in a restricted network.
- Break-glass access: Confirm whether local user accounts remain available alongside SAML and how an administrator signs in if the identity provider is down. Mautic's authentication documentation describes basic authentication for users and SAML as an integration, so verify how the two interact in your release.
- Cron and background jobs: Confirm that scheduled commands run without contacting the identity provider, so segment and campaign processing continues during an identity outage.
Before go-live, rehearse a metadata update and an identity provider outage end to end, and confirm each step with the Mautic release documentation and your network team.
Securing the SSO path and keeping admin access recoverable
Single sign-on depends on the administrator access around it. These six controls cover the local fallback account, the roles federated users receive, the SAML key and configuration secrets, web access, session lifetimes and removal of access when someone leaves. Each card names the risk, the control and the team that owns it.
Tested local administrator fallback
Risk: if the identity provider, the certificate or the SAML settings fail, nobody may be able to sign in to Mautic as an administrator. Control: keep one local administrator account with a long, unique password held in a secrets vault, and confirm it signs in on the live instance before go-live and after each change to the SSO configuration. Document the recovery steps, who may use the account and how each use is logged. Owner: the Mautic platform owner, with the security team holding the credential.
Least-privilege roles for federated users
Risk: the default role given to users created through SSO may carry more permissions than the person needs, exposing contacts, consent records or settings. Control: set the default role for new users to the lowest level that still allows sign-in, and grant elevated roles only after a documented review. Confirm whether your Mautic version can map identity provider groups to roles. If it cannot, make role assignment a manual, logged step. Owner: the marketing operations lead, with the identity team.
Protecting the SAML key and secrets
Risk: the service provider private key, the Mautic configuration file and the database credentials together let an attacker forge sign-in traffic or reach personal data. Control: store the private key outside the web root with restrictive file permissions, keep configuration files out of version control, and load secrets from a vault or environment variables where your deployment allows it. Record the certificate expiry date and rotate before it. Owner: the platform engineering team.
HTTPS and restricted admin URLs
Risk: sign-in responses and session cookies sent over plain HTTP can be intercepted, and an admin login page open to the internet invites password guessing. Control: serve Mautic only over HTTPS with a valid certificate, redirect HTTP to HTTPS, and limit access to admin paths to known networks or a VPN. The SAML response endpoint must stay reachable by the identity provider. Confirm the exact paths for your version before writing firewall rules. Owner: the infrastructure team, with network security.
Session lifetime review
Risk: long sessions on shared or unattended workstations keep administrative access open after the user has stepped away. Control: review the session timeout settings your Mautic version exposes, set idle and maximum session limits that match your policy, and check that the identity provider's session lifetime is set consistently with them. Test after each change, since a timeout set too short can interrupt scheduled campaign work. Owner: the security team, with the Mautic administrator.
Offboarding across identity and Mautic
Risk: Mautic keeps its own user records, so disabling someone in the identity provider may not, on its own, end their Mautic access. Control: confirm in the authentication documentation for your version whether a disabled identity provider account can still reach Mautic. Whatever the answer, add a documented step that disables or deletes the Mautic user during offboarding, and review the list of active administrators on a regular schedule. Owner: the HR and identity team, with the Mautic administrator.
How to test that Mautic SSO works and fails safely
The test plan should prove two things: that the right people get into the right account with the right role, and that every failure stops access cleanly. Run it in a staging instance connected to the same identity provider configuration you plan to use in production, and write down the expected result for each case before testing starts, so reviewers can see that outcomes were not adjusted afterward. Begin with the happy path for a new user who has no Mautic account. The expected result is one new account, created with the default role you chose, with email, first name and last name populated from the assertion. Then test an existing user. The expected result is a login mapped to the existing record, with no duplicate account and no silent change to the user's role unless your mapping rules call for one.
Next, test what happens when the assertion is incomplete. Remove the email attribute from the identity provider's claim set, then rename the first name claim so it no longer matches what Mautic expects. Mautic's documentation says the identity provider must send email, first name and last name, so the expected result is a refused login or a clearly logged failure, with no account created with blank fields or a guessed identity. Record the exact error the user sees and the log entry an operator would search for. Then disable a test user in the identity provider and attempt to sign in with no active Mautic session. The expected result is that the login fails at the identity provider and no new Mautic session is created. Also observe whether an already open session for that user stays active after the account is disabled, because that window determines how quickly offboarding takes effect.
Certificate rotation is the case most likely to break a working integration, so test it before the first production rotation. In staging, rotate the signing certificate in the identity provider and update the certificate Mautic trusts, following the order your change process requires. Then sign in with a test account. The expected result is a successful login with the new certificate, and a failed login when the old certificate is presented or when the metadata is stale. Confirm how your Mautic release handles certificate expiry and metadata updates against the documentation for that release before assuming it matches another version. Record the certificate details and expiry dates before and after the rotation, so the change record shows exactly what was trusted at each point.
Finally, confirm that the local administrator can still sign in when the identity provider cannot be reached. Block network access from the Mautic host to the identity provider in staging, or point the SSO configuration at an unreachable address, then attempt a login with the local admin account. First confirm how your Mautic release keeps the standard login form available alongside SAML, because that setting decides whether this test can pass at all. The expected result is that the local admin signs in and that SSO failures are logged without revealing to the user whether a given username exists. Keep the local account credentials in a sealed, audited location and repeat this break-glass test on a schedule, not only once.
Keep the evidence in a form that a security review or change board can read without help from the test team. For each case, retain the test date, the environment and build version, the test account identifier (never a password), the expected and actual result, and the relevant log excerpts, with timestamps that can be matched to identity provider sign-in logs. Store screenshots of the error pages users see, the certificate details before and after rotation, and the change record that authorized each step. Reviewers will ask whether the tests were repeated after each configuration change, so attach the results to the change ticket. Keep the plan under version control so later changes to attribute mapping or default roles can be compared against the original expected results.
What to monitor, back up and document after SSO goes live
This table lists the recurring checks, backups and records that keep Mautic SSO working after launch, with the purpose of each and the team that should own it. Read it as an operating handover: each row names what to watch or keep and who is accountable. The main takeaway is that an SSO login that worked at go-live can break silently after a Mautic upgrade, PHP change or certificate rollover, so retesting is part of the run book.
| Area | Purpose | Owner |
|---|---|---|
| Login failures and unexpected user creation | Spot SAML assertion errors, misconfigured attribute mappings and accounts created by default role rules that nobody approved. Review failure logs and new-user events on a set cadence. | Mautic administrator with the identity team as escalation |
| Certificate and metadata expiry | Track the signing certificate and identity provider metadata expiry dates in both Entra ID and Mautic. An expired certificate stops all SSO logins, so set alerts well before the date. | Identity team, with the Mautic administrator confirming the stored configuration |
| Mautic configuration backup | Back up the Mautic configuration, including SAML settings, attribute mapping and default role settings, alongside the database and files. Confirm restores work in a test environment. | Platform or infrastructure team |
| Local admin recovery procedure | Keep at least one local Mautic administrator account that works when the identity provider is unavailable. Store its credentials securely, test the recovery steps and record who may use them. | Mautic business owner, approved by the CISO or security lead |
| Role assignment review | Check that users provisioned through SSO hold only the Mautic roles their job requires. Remove access for leavers and confirm that default roles for new users still match the role model. | Mautic business owner, with access reviews run by the identity team |
| Retest after Mautic upgrades and PHP changes | Upgrades and PHP version changes can alter authentication behavior. Repeat the SSO login, attribute, role and logout tests on a staging copy before every production upgrade. | Platform team, with sign-off from the Mautic business owner |
| Attribute contract | Document the required SAML attributes (email, first name and last name) and their source fields in Entra ID. Any change to the identity provider claims can break user creation or matching. | Identity team, with the Mautic administrator as co-owner |
| Role model and owners | Record each Mautic role, what it permits, who approves it and which Entra ID groups map to it. Name a single owner for each record so changes are reviewed, not made ad hoc. | Mautic business owner |
Questions buyers ask about Mautic SSO and outside help
Does Mautic support LDAP or Active Directory directly?
No. The Mautic authentication documentation describes basic authentication for users and SAML single sign-on as the external option, and it describes no LDAP or Active Directory option. Organizations that want directory-based login usually connect Mautic to an identity provider that already draws on Active Directory, such as Entra ID, and use SAML between the two. Confirm this against the documentation for your exact release before you rely on it, because options can change between versions. The identity provider must send the email, first name and last name attributes that Mautic expects. If your plan depends on a direct LDAP bind, treat it as a scope question to settle before any quote is written.
Can we set up SAML single sign-on for Mautic in-house?
Yes, if your team has someone who can configure the identity provider and has tested SAML before. The work has three parts: registering Mautic as a service provider, mapping the required attributes, and deploying the certificate and login settings to the Mautic server. Mautic's documentation names email, first name and last name as the attributes the identity provider must send. Most failures happen in attribute mapping, certificate handling or redirect URLs, so test with a small group of accounts in a staging environment before any production change. In-house delivery is workable only if the team can test and roll back safely.
What drives the cost of a Mautic SSO project?
Most of the cost is people time: configuring the identity provider, configuring Mautic, and testing both against a staging environment. Mautic itself is free open-source software, so there is no license line for SSO, but you still pay for the server, the staging copy and the staff who run the work. The main drivers are the number of identity providers and user groups involved, whether your identity team already runs SAML applications, how many Mautic roles must be mapped, whether the install is on a supported release, and how much testing and documentation your security team requires. One-time costs cover design, configuration and testing. Recurring costs include certificate renewal, identity administrator time for onboarding and periodic checks after upgrades. Ask any provider to split the quote along these lines.
How is a fixed-scope quote for Mautic SSO structured?
A fixed-scope quote lists the scope, deliverables, assumptions, what the client provides and the timeline, and it is agreed in writing before work starts. For SSO, the written scope should name the identity provider, the Mautic version and hosting, the attribute mapping, the default role for created users, the staging and production steps, the test cases and who signs off. It should also name exclusions, such as directory sync or LDAP work if that is out of scope, and any follow-up support. Most DeployOpen engagements are fixed-scope, and the quote follows from that written scope. Ask for each deliverable to be listed separately so you can see exactly what is included and what is not.
How long does a Mautic SSO integration take?
Duration depends on factors you can list before the work starts: the identity provider and its current configuration, how many Mautic environments are involved, the Mautic release and hosting, how many roles and user groups must be mapped, and how quickly your identity administrators can review changes. Expect staging tests and a sign-off window before production. No single number applies to every project, so ask for a timeline that ties each phase to these factors and to dates for client reviews. Certificate changes, changes to the identity provider application and a security review of the login flow can each add time.
What must our internal team provide for a Mautic SSO project?
Plan for named people with time set aside, not only approvals. Typically the internal team provides an identity administrator who can register the application and map attributes, a Mautic owner who can confirm roles and test accounts, and someone who manages the server or hosting for changes. They also need a staging environment that is close enough to production to test the login flow, including the same Mautic release and a reachable test identity provider configuration. Ask the provider to list these needs in the written scope with the expected effort for each role, and to confirm who approves certificate and production changes before the work begins.
Can Mautic enforce single sign-on for all users?
Confirm this before you commit. The documentation for this topic describes SAML as an identity provider integration, but it does not describe a setting that disables local logins for every account, and Mautic uses basic authentication for users, so local accounts may still exist. Do not assume enforcement until the vendor or your release notes confirm how your version handles local login. A safe plan inventories existing local accounts, keeps a documented break-glass path for administrators, tests with non-admin users first, and records the result. Multi-factor policy and other enforcement rules usually sit in the identity provider, so decide those in that system as well.
How do Mautic upgrades affect an SSO integration?
Upgrades can change the integration, so treat SSO as part of every upgrade test. Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and requirements such as PHP versions change between majors. For example, Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5. After each upgrade, check that the SAML configuration, certificates and attribute handling still work on the target release before it reaches production. Mautic 6.0 receives security support until 30 September 2026 and Mautic 5.2 until 30 June 2026, so older installs have shorter support windows. Keep the SSO test cases in your upgrade checklist and a staging copy of the target release.
How DeployOpen works on this
DeployOpen plans and implements self-hosted Mautic inside your own infrastructure, including the SAML single sign-on connection to your identity provider and the user attributes it depends on. Work is agreed as a fixed scope with written deliverables, and ongoing support is available as a retainer.
How we scope
- Confirm which identity provider you use, such as Entra ID, and which Mautic version and hosting model you run
- Record the attributes the provider sends for email, first name and last name, and where they map to Mautic users
- Agree how new users receive default roles and permissions, and who approves role changes
- Document certificate ownership, renewal responsibility and the Mautic login paths that remain outside SSO
How we build
- Configure the SAML connection in Mautic with the agreed entity settings, metadata and signing certificates
- Test sign-in with sample accounts covering new users, existing users and users without the required attributes
- Check that role assignment works for each group before any production users are switched on
- Verify that the basic authentication fallback is handled as agreed, since Mautic's built-in login remains in place
How we hand over
- Deliver a written configuration record covering the identity provider settings, attribute mapping and role defaults
- Provide a certificate and secret inventory with expiry dates and the named owner for each renewal
- Document the test cases used, their results, and steps to repeat them after an upgrade or provider change
- Walk your administrators through sign-in troubleshooting and how to handle a locked-out user
How we support
- Review SSO configuration whenever Mautic moves to a new release, since authentication settings can change between versions
- Track certificate renewals and provider metadata changes so sign-in does not fail unexpectedly
- Support the identity provider changes that affect attributes, groups or role mapping in Mautic
- Offer ongoing support as a retainer, with scope and response expectations agreed in writing
