Setup & Usage Guide

1. Install the app

Secure Fields is distributed through the Atlassian Marketplace as Secure Fields for Jira, for Jira Cloud. A Jira administrator installs it from the listing:

1. Open the Marketplace listing and choose Try it free (or install it from Jira’s own Apps → Explore more apps screen).
2. Pick the Jira Cloud site to install on and approve the app’s three scopes.
3. Licensing is handled by Atlassian: the app is free for sites of up to 10 users, and $1 per user per month above that. While a licence is inactive, stored values are kept untouched but are not revealed, and the admin page will not save rule changes.

The app runs entirely on Atlassian’s infrastructure — there is nothing to host, no account to create with us, and no outbound connection to configure.

2. What Secure Fields does

Secure Fields adds a Secure Text custom field type to Jira Cloud. A value stored in a Secure Text field is held in Forge storage on Atlassian's platform — never written to the Jira field itself — and is shown only to the people you authorize. Everyone else, including anyone reading the issue's REST payload, JQL search results, or a CSV export, sees only a fixed marker in place of the value.

3. Add the field to your project

Creating and placing a Secure Text field uses ordinary Jira field administration — Secure Fields doesn't change this part of the workflow:

1. Jira settings → Issues → Custom fields → Create custom field.
2. Choose the Secure Text field type and give it a name.
3. Add the field to the screens used by the projects where you want it available.

4. Set a protected value

Once an issue exists, click into the field to open its inline editor, type the value, and save. What you see depends on your access:

• No view access, or the page hasn't loaded the value yet: the field shows a masked placeholder (••••••••).
• View access, but nothing has been set yet: No protected value set.
• You try to edit without edit access: You do not have permission to edit this protected value.
• View and edit access: the field shows and lets you change the real value.

Once a value is set, it exists only in Forge storage. Jira's own field data, REST responses, JQL search, and CSV export all show only a constant marker token — never the value, for any caller.

5. Configure who can see and edit a field

Permission rules are managed by Jira administrators from Jira admin settings → Apps → Secure Fields.

1. Pick a field from the list of Secure Text fields on your site.
2. Set view and edit rules separately, each by exact Jira group name and/or project role name. Names are typed, not picked from a directory, so double-check spelling — a misspelled name silently grants access to no one. Anyone who matches an edit rule can also view the field; view access alone does not grant edit access.
3. Use Preview access to check what a specific real user would see under the rules you've drafted — including changes you haven't saved yet — before committing them. Add a project key if your draft includes project-role rules, so those are checked too.
4. Save. A confirmation step lists exactly what will be written before anything changes. Rules take effect immediately.

A field with no saved rules, or rules that fail validation, is masked for everyone until valid rules are saved — access is deny-by-default.

6. Access history

The same admin page includes an audit log covering every successful reveal of a protected value (a real view or edit-prefill — a masked render exposes nothing and isn't logged), every edit, and every change to a field's permission rules. Each record shows who, what, and when — never the protected value itself. Use it to answer "who has seen this value, and when?"

7. Know the tradeoffs

These are consequences of the design, not defects:

• Protected values are not JQL-searchable and don't appear in filters, dashboards, or Jira reports — for anyone, including authorized users.
• Protected values are excluded from Jira's own backups, exports, and site migrations, because they were never stored in Jira. An export-for-backup capability for authorized admins is on our roadmap.
• There's no create-time entry yet — values are set from the issue view, after the issue is saved.
• Cloning an issue does not copy its protected value; the clone starts with nothing stored.

8. Compliance positioning

Secure Fields is a technical access control designed to support compliance programs — HIPAA, SOC 2, GDPR, ISO 27001, and similar — by keeping designated field values out of Jira's data plane and enforcing deny-by-default, server-side access rules. It is not a certification, and using it does not by itself make your organization compliant with any of these frameworks. Your relationship with Atlassian — including any Business Associate Agreement or equivalent — is governed by your own agreement with Atlassian; see the Atlassian Trust Center.

9. Questions

See Support for how to reach us, and our Privacy Policy and Terms for the legal details.