Contextra Secure Field
Setup & usage documentation

1. Overview

Contextra Secure Field adds an encrypted, permission-gated custom field to Jira issues, for values that shouldn’t be readable by everyone who can view the issue — passwords, API keys, tokens, and similar secrets. A matching Secure Attachment field type does the same for a small file instead of a short value.

The core guarantee: the raw value is never the field’s own Jira-visible data. An ordinary Jira custom field stores its value in the clear, where anyone with issue-view permission can read it through Jira’s own REST API — regardless of what the field’s own UI shows or hides. Secure Field stores only a non-reversible marker in that slot and keeps the encrypted value in Forge’s own storage, reachable only through this app’s own permission-checked resolver.

At a glance

2. Prerequisites

3. Installation

1. Open the app’s listing on the Atlassian Marketplace.
2. Click Try it free (or Get it now) and choose the Jira site to install on.
3. Confirm the requested permissions. They are listed in full in section 5.
4. Wait for the install to complete. Nothing appears on any issue yet — the field itself does not exist until you create one, and its allow-list is empty until you configure it. See section 4.

4. Creating the Fields

Installing the app adds two new custom field types to Jira — it does not add a field to any issue by itself, and a newly created field cannot be used by anyone until its allow-list is set.

Reaching the field’s own configuration screen

This is the one step that is easy to get lost in, because it is not linked from the issue itself:

1. Jira Settings → Issues → Custom fields.
2. Find the field, click its … menu, and choose Contexts and default value.
3. Click Create, edit or delete contexts.
4. On the page that opens, find Custom field config and click Edit custom field config.

That last click opens the app’s own configuration screen — the allow-lists, second-factor toggle, auto-expiry, BYOK option, and the migration wizard all live there. It is the same screen for both field types.

5. Permissions

The app requests five scopes, and no others:

Every check is re-derived from Jira, never trusted from the client

Reveal and edit permission are re-checked against Jira’s own APIs on every single request — who the calling user actually is, and whether they match the field’s allow-list, is never taken as given from anything the browser sends. This closes the standard risk of a client simply claiming a permission it doesn’t have.

Runs on Atlassian

The core product declares no external domains and makes no network request to any third party. The encrypted value, per-field configuration, and the audit log all live in Forge’s own storage — operated by Atlassian on the app’s behalf, not a service Contextra Labs runs.

6. Configuration

Open the field’s configuration screen (see section 4). Configuration is per field.

Who can reveal this field’s value?

Deny-by-default: an empty list means nobody can reveal or edit the value, not even a site admin. Add one or more entries of any of these types:

The same list governs both reveal and edit — there is currently no way to let someone set a value without also being able to see it.

Who can view this field’s audit log?

A separate allow-list, of the same entry types, independent of who can reveal the value itself. This lets you grant a project lead or auditor visibility into who accessed the field, without also granting them the ability to see the secret.

Security options

Migrate from an existing plain field

A separate section further down the same screen. See section 10 for the full two-phase walkthrough.

Click Save configuration to apply changes. There is no separate confirmation step for allow-list or security-option changes — only the migration wizard’s clear step requires one, because only that step is irreversible.

7. Setting & Revealing a Value

On an issue carrying the field, anyone on the allow-list sees an input box and a Save button if no value is set yet, or a masked •••••••• with a Reveal button and a Change value option if one is.

1. Type the value and click Save. It is encrypted before it ever leaves the resolver — the field immediately shows the masked form.
2. Click Reveal to decrypt and display the value. The app re-checks your permission against Jira at this exact moment, not just when the page loaded.
3. Click Change value to overwrite it — the same allow-list gates this as revealing does.

What someone outside the allow-list sees

Deliberately generic — it never hints at who is allowed, to avoid leaking the allow-list itself to someone who isn’t on it. Every denied attempt is written to the audit log regardless.

8. Two-Factor Confirmation & Audit Log

Two-factor confirmation

When enabled for a field (section 6), clicking Reveal issues a one-time verification code and shows a code-entry box instead of the value immediately:

Enter the code and click Confirm — on success the value reveals automatically in the same action. This gate is real and enforced server-side; see the limitation on delivery in section 13 before relying on it for a live rollout.

Audit log

A View audit log button appears below the field’s value on every reveal-capable surface. Anyone on the field’s separate audit allow-list (section 6) sees a chronological list of entries, each formatted as timestamp, action, and the account that triggered it. Recorded actions include:

The log is append-only — there is no way, in this app, to edit or delete an existing entry.

9. Auto-Expiry & Bring Your Own Key

Auto-expire after N hours

Leave blank for a value that never expires, or enter a number of hours. Once a revealed value is past that age, the field clears itself and reports:

An expired value is genuinely gone — there is no way to recover it once its TTL has passed, by design. If you change a field’s TTL after a value was already saved under a shorter one, the value can expire earlier than the field’s current setting suggests; this is disclosed behaviour, not a bug, and is reported the same way as an ordinary expiry, never as a decryption error.

Bring your own encryption key

An optional checkbox, worded on the screen itself exactly as bluntly as it should be: “Bring your own encryption key (irreversible if the key is lost).”

10. Migrating an Existing Plain Field

If you already have a plain Jira field holding values that should have been encrypted from the start, the migration wizard — on the same configuration screen, below Security options — copies them in, in two clearly separated phases.

Phase 1 — copy (never moves)

1. Enter the source field id (for example customfield_10001) — the plain field you’re migrating from.
2. Enter one or more issue keys or ids, separated by commas, spaces, or newlines (for example SCRUM-1, SCRUM-2).
3. Click Run migration (copy only).

Each issue reports its own result — a per-issue list, never a single pass/fail flag:

The original field is never touched by this step. One issue’s failure never stops or rolls back the others.

Phase 2 — clear the original (irreversible, separately confirmed)

Only offered for issues phase 1 actually reported copied — never for a failed or skipped issue, since there would be nothing safely migrated to clear the original for. The screen states the stakes before you can proceed:

The Clear original values button stays disabled until you type the exact phrase CLEAR ORIGINAL VALUES into the confirmation box — deliberately more friction than a checkbox, for a step with no rollback.

11. JSM Requests & Safe JQL Search

A Secure Field added to a Jira Service Management request type appears on the portal request form for requesters and the portal view for agents, using the exact same allow-list, encryption, and audit behaviour as the issue-view surface. JSM request participants is one of the allow-list entry types (section 6) specifically for this surface.

Searching without leaking

Use Jira’s own IS EMPTY / IS NOT EMPTY JQL operators to find issues where the field has, or doesn’t have, a value set — for example cf[10146] IS NOT EMPTY. This works through Jira’s native structural check, needs no custom JQL function from this app, and can never expose what the value actually is — only whether one exists. CSV export and print view show only Not set or ••••••••, the same as the field’s own masked display.

12. The Secure Attachment Field

Contextra Secure Attachment is a second field type in the same app, sharing the identical allow-list, audit log, two-factor, and configuration screen as the text field — only the stored content differs: a small encrypted file instead of a short value.

• Files are stored encrypted, out of Jira’s native Attachments panel entirely — not just hidden from it.
• Reveal and download follow the exact same allow-list as the text field type.
• 90 KB per file — a real, disclosed limit from how the encrypted envelope is stored (Forge’s key-value store), not an arbitrary choice. Larger files belong in Jira’s native attachments, or in File Field for Jira if they need upload rules instead of encryption.
• Configuration — the allow-lists, 2FA, TTL and BYOK — is the exact same screen used for the text field type, reached the same way (section 4).

13. Limitations

These are published rather than buried, because finding them after paying is worse for everyone.

14. Troubleshooting

15. Support

• Email support@contextra-labs.com — questions, bug reports and feature requests all go to the same place.
• Support page — response times and what to include in a report.
• Atlassian Marketplace listing ↗
• Privacy policy · Security policy · Terms & EULA

When reporting a problem with a specific field, the most useful details are the field’s name and type (Secure Field or Secure Attachment), whether two-factor or an auto-expiry TTL is enabled, and the exact message it showed.