JSM Cloud password/session controls for portal-only customers

[#1]

Hi all!

We're going through a security audit under Spain's ENS (Esquema Nacional de Seguridad — the national security framework required for public-sector suppliers, broadly comparable to other national/industry security baselines) and it flagged a recurring gap in Jira Service Management : identity controls for our external customers (portal-only accounts, which live in Jira's local customer directory rather than a federated IdP). Specifically, the audit requires these users to have:

1. Password expiration — portal-only account passwords currently never expire.
2. Account lockout after N failed login attempts, with an admin-configurable threshold.
3. Password history — blocking reuse of the last N passwords (e.g. the previous 3).
4. A mandatory "I accept the Terms & Conditions" checkbox when the customer receives their password or logs in for the first time.
5. Visibility for the end user of their own last login date/time after authenticating.

Before asking, we dug into what Atlassian provides out of the box, and none of the five points are natively covered for portal-only accounts:

• Atlassian Guard password policies only apply to managed accounts on a domain your organization has verified. The official docs are explicit: "You can't create a password policy for Jira Service Management customers with portal-only accounts."
• There's no admin-configurable lockout threshold in Cloud at all (managed or portal-only) — only a non-configurable CAPTCHA/throttle triggered by anti-bot heuristics, with no adjustable threshold or duration.
• Password history/reuse prevention doesn't exist in Cloud, period.
• There's no native ToS acceptance checkbox in the customer portal. The one Marketplace app that implements this (Terms and Conditions for Jira) is Data Center/Server only, not Cloud.
• There's no end-user-facing "last login." Even the internal admin-facing Last Active field is unreliable for portal-only customers, since it doesn't update when a customer interacts by email only.
• This is a known, tracked gap: JSDCLOUD-8323 (open since 2019, ~180 votes). An Atlassian PM confirmed on the ticket they're evaluating it, with no committed timeline. The only official workaround given is migrating customer authentication to external SAML SSO.

The actual question: if you run JSM  with external customers under a framework that mandates these controls (ENS, ISO 27001, SOC 2, NIST 800-63, or similar), what did you actually end up doing in production?

• Did you move portal-only customers to SSO with an external IdP (Entra ID, Okta, Keycloak...)? If your customers don't have their own corporate IdP, did you stand up a CIAM (Entra External ID, Auth0, Okta CIC) just to host their identities?
• Did you cover the ToS checkbox and/or last-login display with a custom app? Any gotchas (e.g. the June 2026 consent-prompt issue that briefly blocked Forge apps for portal-only customers)?

Any real-world detail  would help a lot. Thanks in advance. 

Kind regards!

[David Gray]

We have not addressed this, but as an Admin for a JSM instance I cannot confirm which portal users have enabled 2FA, this would be good to see.