Can ScriptRunner do what Secure Admin does?

Partially — and only with caveats. ScriptRunner can execute admin-level operations via scripts, but it does not natively offer a model where a non-admin can be granted limited admin powers through a UI. Scripts run with elevated privilege, meaning the script author effectively has full admin rights. Secure Admin's model is the inverse: explicitly grant a named user a named limited admin capability, without giving them the keys to the kingdom and without writing code.

Does Secure Admin replace the Jira system administrator role?

No. Secure Admin sits beside the existing admin role. System administrators still exist and retain their full powers. Secure Admin lets those system admins safely delegate a narrowly defined slice of their work — say, 'edit notification schemes' or 'manage a specific project's workflow' — to a named user, without elevating that user to full admin.

Is this a security concern with ScriptRunner?

Not inherently — ScriptRunner itself is a legitimate, well-supported product. The concern arises when teams use scripts as a delegation mechanism: anyone who can edit a script can effectively re-grant themselves admin privileges. ScriptRunner has script-edit-permission features to mitigate this, but those features are about restricting which admins can edit scripts, not about granting limited admin powers to non-admins. The two products solve adjacent but distinct problems.

Is Secure Admin available on Jira Data Center?

Yes. Secure Admin ships both a Cloud edition and a Data Center edition with the same delegation model. ScriptRunner is also available on both. Always check the live Marketplace listing for the current supported version range.

Secure Admin vs ScriptRunner for Jira — Which Admin-Delegation Approach Should You Pick?

This comparison is for Jira admins evaluating Secure Admin by Redmoon Software against ScriptRunner for Jira by Adaptavist as approaches to delegating admin work. They aren’t direct competitors in the usual sense — they’re two different answers to the same underlying question: how do I let someone do admin-y things without making them a full Jira admin?

The 30-second answer

Secure Admin is a declarative delegation product. You define which limited admin powers a user or group should have — through a UI, with an audit log of every action — and that user gains exactly those powers and nothing else. They don’t need scripting skills. They don’t get the rest of admin.

ScriptRunner is a Groovy scripting platform. Scripts execute with elevated privilege, which means a sufficiently skilled author can perform any admin action via code. Limiting who edits scripts is itself a problem ScriptRunner addresses through Script-Edit Permissions, but that’s restricting admins, not empowering non-admins safely.

If your problem is “I want to safely give a specific person limited admin rights” — Secure Admin. If your problem is “I want to automate admin work via code” — ScriptRunner. These are different doors into the same building.

Side-by-side

Capability	Secure Admin	ScriptRunner
Non-admin can be granted limited admin powers	✓	✗
Delegation defined through UI (no code)	✓	✗
Granular per-capability scope (e.g. notifications only)	✓	Via script restriction
Audit log of delegated actions	✓	Via Jira audit
Time-limited / scope-limited delegation	✓	✗
Per-project delegation scope	✓	Via script
Group-based delegation	✓	Via script
General-purpose Groovy scripting platform	✗	✓
Script-edit permission restriction	N/A	✓
Console for ad-hoc Groovy execution	✗	✓
Custom JQL functions, scripted fields, listeners	✗	✓
Workflow post-function scripting	✗	✓
Designed for delegation	✓	✗
Designed for automation	✗	✓
Jira Cloud edition	✓	✓
Jira Data Center edition	✓	✓

When Secure Admin is the right pick

You want to reduce the number of full Jira admins. Every full admin is a risk surface. Secure Admin lets your project leads, team captains, or department managers handle their own configuration changes (workflows, notifications, screens) without being granted full admin. Audit teams routinely flag “too many full admins” as a finding; this is the standard remediation.
The work to delegate is non-code-y. Editing a notification scheme, managing a permission scheme, adding a custom field — these are configuration tasks, not scripting tasks. ScriptRunner is the wrong tool because nobody is going to write Groovy to do them, and granting full admin to delegate them defeats the purpose.
You need a clear audit trail tied to a named delegated user. Secure Admin records every delegated action against the human who performed it. That maps cleanly to SOX / ISO 27001 segregation-of-duties controls.
You don’t have Groovy skills on the team. Secure Admin works for project admins, ITSM team leads, and HR admins who will never write a line of code.

When ScriptRunner is the right pick

You need automation, not delegation. Automatically transition issues when a webhook fires; run a scheduled JQL-driven cleanup; expose a custom REST endpoint — these are scripting jobs, not delegation jobs. ScriptRunner is squarely the right tool.
You have a Jira platform team with Groovy expertise. A central Jira engineering team that already maintains scripts can use ScriptRunner to extend Jira in ways no declarative tool can match.
You need scripted fields or custom JQL functions. ScriptRunner is the canonical Atlassian Marketplace tool for these.
You’re consolidating onto one extension platform. If you already have ScriptRunner deployed for other reasons, using its Script-Edit Permission model to restrict who can edit existing automation scripts is a reasonable next step.

They solve different problems — usually run both

Almost no mature Jira tenant runs only ScriptRunner or only Secure Admin. They sit on different axes:

Secure Admin is the delegation axis — granting limited admin powers to humans, safely.
ScriptRunner is the automation axis — letting code do admin-y work on a schedule or in response to events.

A typical pattern: ScriptRunner handles the recurring automation (scheduled scripts, REST endpoints, scripted listeners). Secure Admin handles the human delegation (project leads who manage their project’s config without being full admins). Both are gated by audit logs. The two together let a Jira admin team scale beyond what either tool alone enables.

A note on security

Treating ScriptRunner as a delegation tool is a known anti-pattern: any user who can edit a script effectively has whatever permissions the script runs with, which is typically full admin. ScriptRunner mitigates this with Script-Edit Permissions, which lets system admins restrict which admins can edit scripts. That helps limit blast radius among admins but does not enable safe delegation to non-admins. Secure Admin’s model is structurally different — capabilities are granted through configuration, not by being able to write code.

If your goal is segregation of duties for audit purposes, Secure Admin maps cleanly to that requirement; ScriptRunner-based delegation does not.

Cost considerations

Both apps are priced on the Atlassian Marketplace, tiered by Jira user count. ScriptRunner is a broad, premium platform; Secure Admin is a focused delegation product. Pricing is best read from the live Marketplace listings:

For teams whose problem is delegation, Secure Admin is typically dramatically cheaper than ScriptRunner because the scope is narrower. Teams who need ScriptRunner usually need it for reasons unrelated to delegation, and the cost is justified by automation rather than by delegation.

Get started

The fastest way to evaluate Secure Admin is to install the free trial, delegate a single capability (e.g. “edit notification schemes for the Marketing project”) to a named user, log in as that user, and confirm they can do that one thing and nothing else.

Start Secure Admin free trial ↗ Secure Admin overview →