Crowd is mainly centralized user management and SSO for self-managed Atlassian apps, not a full MFA enforcement product by itself. For non-cloud Atlassian tools, the usual pattern is to put MFA in front of Crowd or in front of each Atlassian Data Center app through an external IdP.
Common implementation patterns
1. Use SAML/OIDC SSO for Atlassian Data Center and enforce MFA at the IdP
This is usually the cleanest approach.
Atlassian provides SSO for Atlassian Data Center, which lets Jira, Confluence, Bitbucket, Bamboo, and Crowd connect to an identity provider using SAML or OpenID Connect. Atlassian’s docs list support for Jira Software Data Center, Jira Service Management, Bitbucket, Confluence, Bamboo, and Crowd, and say the SSO app can connect Atlassian Data Center applications to an IdP. [confluence...assian] , [confluence...assian]
So the design becomes:
1
User
2
-> Atlassian app login
3
-> SAML/OIDC redirect
4
-> IdP, for example Entra ID, Okta, Ping, ADFS, Duo-backed IdP
5
-> MFA enforced by IdP
6
-> Atlassian app session
Crowd can still remain your user directory / group source, while authentication is delegated to the IdP.
2. Delegate authentication to Crowd, but do MFA elsewhere
The Atlassian SSO documentation says SSO for Data Center can alternatively delegate authentication to Crowd. The Atlassian Marketplace listing for “SSO for Atlassian Data Center” also says it supports multiple IdPs and can delegate authentication to Crowd. [confluence...assian.com] [marketplac...assian.com]
That helps with centralized login, but if users are authenticating directly against Crowd username/password, Crowd itself is not where I’d expect strong MFA policy enforcement to live. In that model, you typically need:
- IdP MFA in front of Crowd, or
- a Marketplace MFA/SSO app, or
- reverse proxy / access gateway MFA before Atlassian apps
3. Use a third-party Marketplace app for MFA on Server/Data Center
If you need MFA directly on Jira/Confluence/Bitbucket/Crowd login flows, many organizations use Marketplace apps from vendors such as miniOrange, Kantega, or similar. For example, miniOrange advertises SSO/MFA options for Atlassian Data Center and Crowd SSO connectors. Kantega’s documentation says SAML and OIDC providers can be configured to use MFA. [miniorange] , [miniorange.com] [kantega-ss...assian.net]
I’d treat vendor claims carefully and test against your exact Atlassian product versions, especially if you still have legacy Server products rather than Data Center.
What I would recommend
For non-cloud Atlassian tools, I’d avoid trying to make Crowd the MFA authority. I’d use:
1
Atlassian Data Center app
2
+ Atlassian SSO for Data Center
3
+ SAML or OIDC IdP
4
+ MFA policy in the IdP
5
+ Crowd as user/group directory if still needed
That gives you centralized MFA policy, conditional access, logging, and lifecycle controls in the IdP, while preserving Crowd’s role for directories and group mappings.
Important caveat
Atlassian’s Data Center SSO docs explicitly say SSO handles authentication, while application access and authorizations should still be configured in the user directory and/or the application. So MFA solves login assurance, but you still need group/permission governance in Crowd, LDAP/AD, and the Atlassian apps themselves. [confluence...assian.com] , [confluence...assian.com]
One practical next step: inventory whether each of your Jira/Confluence/Bitbucket/Bamboo/Crowd versions supports Atlassian’s current SAML/OIDC SSO app, then choose whether MFA will be enforced in Entra ID, Okta, Ping, ADFS, Duo, or another IdP.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.