Passwords and API keys
don't belong in plain text
A standard Jira custom field's value is readable by anyone with issue-view permission through Jira's own REST API — CSV export and JQL included. Secure Field encrypts the value server-side and only reveals it to people you explicitly allow, with a full audit trail of who saw what.
What actually changes, not just what's on screen
Masking a value in the UI is not the same as protecting it. This is the difference that matters.
An ordinary custom field
What Jira gives you by default- Its value is the field's own Jira-visible data — readable by anyone with issue-view permission through Jira's own REST API.
- Shows up in CSV exports, JQL result columns, and print view exactly as typed.
- Any Forge or Connect app with read access to the project can read it too.
- No record of who looked at it, or when.
Contextra Secure Field
Encrypted, permission-gated- The raw value is never the field's own Jira-visible data — only a non-reversible marker ("has a value or not") is.
- CSV exports, JQL results and print view show only "Not set" or "••••••••" — never the content.
- Reveal is gated by a per-field allow-list, re-checked against Jira on every single request.
- Every reveal, edit, and denied attempt is written to an immutable audit log.
Built for real
secret handling
AES-256-GCM, server-side only
Encryption and decryption happen only inside the resolver, never in the browser. The field's own Jira-visible schema value is only ever {v, hasValue, updatedAt} — never ciphertext, never a decryptable reference.
Deny-by-default, per field
An empty allow-list means nobody can reveal or edit the value — not even a site admin — until you explicitly add a user, group, project role, assignee, reporter, creator, project lead, or JSM request participant.
Immutable audit log
Every reveal, edit and denied attempt is appended to a log nothing can rewrite. Audit visibility is its own, separately configurable allow-list — grant it to a project lead or auditor without also granting reveal access.
Optional second-factor confirmation
Require a one-time code before a value reveals, on top of the allow-list check — an additional gate against a compromised or coerced session, configurable per field.
Auto-expiry (TTL)
Set a field to forget its value automatically after a configured number of hours. An expired value clears itself from Jira and reports "expired," never a scary decryption error.
Bring your own encryption key (optional)
Supply your own key instead of the app-managed default, for teams whose security posture requires it. A materially different, and irreversible, tradeoff — see the limitations below before enabling it.
Safe JQL search
Search for issues where the field "has a value" or "is empty" using Jira's own native IS EMPTY / IS NOT EMPTY operators — a purely structural check that never exposes what the value actually is.
Migrate an existing plain field
A two-phase wizard encrypts an existing plain field's values, issue by issue, without touching the original — then only clears the original once an admin explicitly confirms the copy is correct, in a separate, clearly irreversible step.
A matching attachment field
The same encryption and permission model, for a small file instead of a short value — a signed document or credential file, up to 90 KB, stored out of Jira's native Attachments panel.
What this app does not do
We would rather you read this now than discover it after paying.
- A value can only be set once the issue exists — not on the issue-create screen. This is a deliberate platform-imposed limit, not an oversight: the Forge APIs this app was checked against give the create screen no way to hand a not-yet-created issue's id to the field, and the only alternative would mean writing the plaintext value into Jira's own visible field, which is exactly what this app exists to prevent. Set the value from the issue view once it's created.
- Two-factor confirmation gates reveal, but code delivery is not yet wired to a real provider (SMS, email or authenticator push). The gate itself is real and enforced; sending the code to the user is the part still pending a chosen vendor.
- Webhook alerts on reveal/denied events are built but not yet enabled — the app does not currently declare the network permission a fully customer-supplied alert URL would need. Until then, the audit log is the record of every reveal and denial.
- Bring-your-own-key is irreversible if the key is lost. There is no recovery path — a lost BYOK key means the encrypted value cannot be decrypted again, ever. Enable it only if your organization can guarantee the key's own custody.
- Attachments are capped at 90 KB per file — a real, disclosed limit from how the encrypted value is stored, not an arbitrary choice. Larger files should stay in Jira's native attachments or File Field for Jira.
- Adding a field to an issue takes a few admin steps beyond creating it — screens and contexts, and on team-managed projects, the project's own field list and each work type's layout. See the documentation for the full chain.
Try it on a free evaluation period
No credit card required. Install from the Atlassian Marketplace and evaluate on your own project. If your evaluation lapses, the field stops accepting new saves or reveals — values already stored stay encrypted, not deleted.