Jira Service Management Security: Securing Portals, Customer Access, Email and Assets

A Jira Service Management help centre is deliberately open to people outside your licensed workforce, so the settings that decide who can become a customer, who can see whose requests and who can email a request in are security controls, not just service design choices. This guide covers the service-level layer of Jira Service Management Cloud: licensed agents versus customers and the Service Desk Team role, customer access and account creation, request sharing and organisations, the email channel and DMARC, Assets roles, automation credentials and the Jira audit log. Organisation-level controls such as identity providers, managed accounts and Atlassian Guard are covered in the Atlassian Cloud Security Guide and are not repeated here. Product facts come from Atlassian's own support documentation, checked on 8 November 2026; hardening stances, alerts and metrics are NHI Mgmt Group guidance. These are customer-side settings under the shared responsibility model. It is written for Jira administrators, service space administrators and security teams.

This is an independent guide from NHI Mgmt Group, based on Atlassian's public documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Product features change, so confirm settings against Atlassian's current documentation.

Key takeaways

• Customers are identities too. Customers raise, comment on and share requests without an agent licence, so the population that can reach your portal is often larger than your workforce and needs its own controls.
• Account creation is a site-wide switch. "Allow customers to create accounts" is global and cannot be limited to one service space; separate internal and external audiences with domain restrictions or a separate site.
• Sharing settings decide who sees what. Customers can share requests within their organisation, with any customer by email, or with anyone found by search, and each option widens visibility.
• Turn on DMARC for the email channel. DMARC incoming email authentication takes precedence over allowlists and is always enforced on Atlassian-provided addresses; enable it for your custom addresses too.
• Assets roles are layered. App admin carries implicit Object schema manager rights on every schema, and an object type role overrides the schema role for that type, so review both levels.

How identity and access work in Jira Service Management

People reach a service space in three ways. Agents hold a Jira Service Management licence and work requests. The Service Desk Team role, as Atlassian describes it, can view work items, add internal comments and attach files without a licence, and cannot be assigned work or receive SLA notifications unless an admin configures it. Customers raise and comment on requests through the help centre portal, email or widget, and share requests, without a licence. Customers can be portal-only accounts, which by default belong to the Service Project Customer - Portal Access permission group, or people who already have accounts on the site.

Single sign-on and MFA for agents and admins are configured at the organisation level through your identity provider and authentication policies; see the Atlassian Cloud Security Guide and the Identity Provider and SSO Security Guide.

Customer access and account creation

Two layers decide who can raise requests. At product level, Settings > Products > Customer Access sets portal access to "Don't allow customers to create their own accounts" or "Allow customers to create accounts". At service space level, customer permissions decide who can raise requests:

Atlassian notes that "Allow customers to create accounts" cannot be scoped to one space, and points to domain restrictions or a separate site for external customers when tighter control is needed. Decide the model per site: if any space must accept the public, keep sensitive internal services on restricted spaces, or on a separate site, so open sign-up never reaches them.

Request sharing and organisations

Customer sharing settings decide whom customers can share requests with:

1. Within their organisation: customers share only with other members of their organisation. Customers outside any organisation cannot share. Narrowest option.
2. Any customer by full email address: the recipient becomes a customer of the space. Suited to internal IT where staff add colleagues.
3. Any customer or organisation by search: customers can search the space's customers, which can reveal names, and recipients not yet in the space receive a "Customer Invited" email. Suited only to public support where names are not sensitive.

Shared people become request participants who can comment, share or view and receive notifications. Atlassian also notes that user picker fields such as Approvers show more names only when sharing uses organisation or space-wide search, so widening sharing to fix an approvals field also widens who customers can discover. Use organisations to group each external company's customers, and keep sharing at organisation level for external audiences.

Admin roles and privileged access

• Permission schemes: sensitive spaces (HR, security incidents, legal) should use their own permission scheme so a change to the shared default scheme does not open them. Changes to permission schemes and global permissions appear in the Jira audit log.
• Issue security: where you use issue security levels, Atlassian notes the levels must allow the "Service project customers - portal access" group, or customers may lose sight of their own requests. Grant exactly that, not wider groups.
• Least privilege: see the Least Privilege Techniques Guide.

Assets object permissions

Assets, the configuration management database in Jira Service Management, often holds hardware, software, owners and network details, which is useful reconnaissance for an attacker. Access has two parts: an Admin Hub product role (User, App admin, or User access admin, which manages the User role without granting Assets access) and in-product roles.

Atlassian documents that an object type role overrides a schema role for that object type: a schema developer can drop to view-only on a type where a different group holds object type developer. Use this deliberately to ring-fence sensitive object types, and record it, because it surprises people during reviews. See the Asset Inventory and CMDB Security Guide.

Integrations, API tokens and service accounts

Service management attracts integrations: monitoring tools that open incidents, HR systems that raise onboarding requests, chat apps, Marketplace apps and scripts that import Assets data. Each one is a non-human identity.

• Use Atlassian service accounts: run integrations under organisation-managed service accounts with scoped API tokens or OAuth 2.0 client credentials rather than a person's account, so access survives staff changes and is visible to admins. Token types, expiry and admin controls are covered in the Atlassian API Tokens Security Guide and the Atlassian API Token Expiry guide.
• Grant to the space, not the site: an alerting integration that creates incidents needs to create requests in one space; give its account only that.
• Assets imports: give import accounts Object schema developer on the target schema, not App admin.
• Automation rules: rules run as a configured actor. Review rules that send web requests or emails to external addresses, because they can move request data out silently.
• Marketplace apps: approve apps through a request process with a named owner and review the data scopes they request. See the SaaS Security Guide.
• Secrets in requests: customers and agents paste passwords and keys into requests. Set a rule for agents to redact and rotate, and scan attachments and comments where your tooling allows. See the Secrets Management Guide.

The email channel

Email is the easiest channel to abuse: a forged sender address can raise a request or add a comment as if it came from a real customer, for example to ask an agent to reset a password or change bank details (ATT&CK T1566). Atlassian documents that an email sender must be a customer with the Create Issue permission, so customer access settings govern email as well as the portal. For sender authentication:

1. Enable DMARC checks: at Settings > Products > Jira Service Management > Email requests, turn on DMARC incoming email authentication (site admin only). It is configured separately from the Jira setting.
2. Know the precedence: Atlassian states that DMARC takes precedence over allowlists, and that on Atlassian-provided Jira Service Management addresses DMARC is always enforced, so a failing message is blocked even from an allowlisted sender.
3. Plan for forwarding: forwarded mail often fails DMARC. Atlassian notes that a custom email address gives more control; connect the mailbox directly rather than forwarding where you can.
4. Use allowlists and blocklists as filters, not authorisation: they decide which mail the channel processes; customer access decides who may raise requests.
5. Verify high-risk requests out of band: password resets, MFA resets, payee changes and access grants raised by email should be confirmed through a second channel. See the Vishing and Help Desk Social Engineering Awareness Guide.

Your own domain's DMARC policy matters too: if it is at p=none, forged mail claiming to be from your staff may still pass to the channel. See the DMARC, SPF and DKIM Guide.

Logging and detection

The Jira audit log is at Settings > System > Audit Log and needs the Administer Jira global permission; Atlassian notes it is not available when all Jira Cloud apps are on the Free plan. It records configuration changes rather than all activity: spaces created, removed or updated, permission schemes and global permissions granted to or removed from groups, workflows, notification schemes, fields and work item deletions; user management events can be found by searching. Retention is chosen under Actions > Audit Log Settings. Export produces a CSV of up to 100,000 events, and the REST API also supports export. Organisation-level events such as sign-ins and token creation come from Atlassian Administration; see the Atlassian Cloud guide. Email processing outcomes are visible in the email logs.

Set retention to match your policy and export to your SIEM. See the SaaS Audit Log Retention and Licensing Guide.

Metrics: sensitive spaces set to Restricted (target 100 percent); spaces using search-based customer sharing (target only public support); integrations on service accounts rather than personal accounts (target 100 percent); Assets App admins (target three or fewer); DMARC authentication enabled for every custom email address (target 100 percent); days since last access review of agents and Service Desk Team.

Hardening baseline

1. Inventory: list every service space with its audience (internal, named external, public), customer permission, sharing setting, email addresses, permission scheme, automation rules and integrations.
2. Decide the site model: if public sign-up is needed, consider a separate site for external customers; otherwise set Customer Access to "Don't allow customers to create their own accounts" or restrict by domain.
3. Restrict sensitive spaces: set HR, security, legal and finance spaces to Restricted with dedicated permission schemes. Test with a pilot customer before switching.
4. Narrow sharing: move external spaces to organisation-level sharing. Check approval fields still work.
5. Email: turn on DMARC incoming email authentication, connect mailboxes directly, and write the out-of-band verification rule for high-risk requests.
6. Assets: reduce App admins, assign schema roles per schema and ring-fence sensitive object types.
7. Integrations: move integrations to service accounts with scoped tokens, then revoke tokens tied to personal accounts.
8. Logging: set audit log retention, export to the SIEM, build the alerts above.

Record each setting before you change it so you can roll back if a customer group loses access.

Common misconfigurations

• Open account creation on a site that also hosts internal spaces: anyone who signs up can reach every open space. Restrict sign-up or split sites.
• Sensitive spaces on the shared default permission scheme: one change to the default opens HR or security requests. Give them their own scheme.
• Search-based sharing on external spaces: customers can discover other customers' names. Use organisation sharing.
• Email requests trusted as identity: agents act on a password or payee change because it came "from" the right address. Turn on DMARC and verify out of band.
• Integrations under a former admin's personal token: move to service accounts with scoped tokens.
• Assets App admin handed out for convenience: it carries schema manager rights on every schema. Use per-schema roles.

Framework mapping

Practitioner checklist

• Classify every service space as internal, named external or public, and set customer permissions to match.
• Set Customer Access to block self sign-up unless a public space needs it; separate public spaces onto their own site where practical.
• Give HR, security, legal and finance spaces Restricted access and their own permission schemes.
• Keep external customer sharing at organisation level.
• Turn on DMARC incoming email authentication and connect mailboxes directly.
• Require out-of-band verification for password, MFA, payee and access changes requested by email or portal.
• Limit Assets App admins and use schema and object type roles to ring-fence sensitive data.
• Run integrations under service accounts with scoped tokens and named owners.
• Set audit log retention, export to the SIEM and alert on permission and Customer Access changes.
• Review agents, Service Desk Team members and customer lists quarterly.

Standards and references

• Atlassian: How to Manage Access to Jira Service Management Projects and Requests
• Atlassian: Resolve Incoming Email Permissions in Jira Service Management Cloud
• Atlassian: Jira and Jira Service Management Cloud DMARC Settings
• Atlassian: Assets Roles and Permissions
• Atlassian: Audit Activities in Jira Applications
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Atlassian Cloud Security Guide · Atlassian API Tokens Security Guide · Asset Inventory and CMDB Security Guide · Vishing and Help Desk Social Engineering Awareness Guide