Security Overview

Secure Fields adds a "Secure Text" custom field type to Jira Cloud for teams that handle regulated information — patient identifiers, account numbers, case details — inside their workflows. Jira has no field-level permissions: any user who can see an issue can see every field on it, through the UI, the REST API, JQL search, and CSV export. Secure Fields exists to close that gap for the specific values you choose to protect.

This document explains, in verifiable terms, where protected values live, who can read them, and what the app deliberately does not do.

1. Where protected values live (and where they don't)

The protected value is never stored in Jira. When a user saves a secure field, the Jira field itself receives only a constant, non-sensitive marker — the literal text [secured] — which is the same for every value in every issue and therefore carries no information. The real value is written to Forge hosted storage (Atlassian's storage platform for apps), using Forge's Secret Store, the mechanism Atlassian designates for sensitive data. Secret Store values are excluded from the storage query API, and each app installation's storage is isolated by the platform.

Because the value is structurally absent from Jira, it does not appear in:

• REST API responses (GET /rest/api/3/issue/{key} returns only [secured]),
• JQL search results (the field is not text-indexed at all; Jira rejects text operators against it),
• CSV and other issue exports (the column shows [secured]),
• Jira webhooks, issue payloads, or anything else that reads the Jira field value.

This is not a masking layer applied on output — there is nothing in Jira to mask.

Verified behavior. We test this on a live Jira Cloud site with an authorized and an unauthorized account: full REST payload sweeps (fields=*all) contain zero occurrences of the protected value for either account; JQL searches for the value return nothing; CSV exports contain only the marker; the unauthorized account's rendered field shows a masked placeholder. The automated suite re-runs on every change to the value path.

2. How access decisions are made

All reads and writes of protected values go through the app's backend (a Forge resolver function). The browser never receives a value that the backend has not already authorized for that specific user.

• Server-side identity only. Authorization uses the user identity that Atlassian's platform supplies to the backend invocation — which Atlassian documents as secure and unalterable — never identity or context information sent from the browser, which a user could modify.
• Deny by default. A field with no permission configuration, or with configuration that fails validation, renders the masked placeholder for everyone. Every lookup failure fails closed.
• Group- and project-role-based rules. Jira admins configure, per field, which groups and project roles may view and which may edit.
• Edit implies view. A user matching an edit rule can also view (an editor that cannot see the current value is incoherent). View access never implies edit.
• Membership checks run under the app's own identity. The app queries group and role membership using its app identity (Forge asApp()), keyed by the platform-supplied user ID. Nothing a field viewer triggers ever acts under the viewer's own credentials.
• Admin-gated configuration. Reading or writing a field's permission rules requires Jira administrator permission (global ADMINISTER), checked server-side on every call. The admin surface is the only place the app acts under the calling user's identity (asUser()): to confirm the caller is an admin, and for the admin page's user search — which uses the admin's own browse-users permission. The configuration surface never touches protected values.
• Typo protection for rules. The admin page includes a "Preview access" check that evaluates draft rules against a real user before saving, plus an explicit confirmation step listing exactly what will be written.

No sensitive values in logs. The app logs keys and IDs only — never payloads, never stored values. Error messages shown to users never contain protected values.

3. Encryption

Protected values are encrypted at rest on Atlassian's platform and encrypted in transit. Specifically, per Atlassian's published documentation:

• The Forge shared responsibility model lists, as Atlassian's responsibility: "Encrypt data at rest for data stored within Forge app storage" and "Use TLS to encrypt all traffic, including HSTS."
• The Forge Secret Store — where protected values are kept — stores key-value pairs "in a secure, encrypted manner" and is Atlassian's designated mechanism for sensitive data.
• Atlassian's Trust Center states that "any customer data in Atlassian cloud products is encrypted in transit over public networks using TLS 1.2+ with Perfect Forward Secrecy (PFS)", and that Atlassian uses the underlying cloud provider's key management service (KMS).

What we deliberately do not claim: Atlassian's published AES-256 statement is scoped to data drives for a named list of products (Jira, Confluence, Bitbucket, etc.) and does not name Forge hosted storage. We therefore do not state a specific cipher standard for stored values, and will not until Atlassian publishes one for Forge storage. Encryption of Forge-hosted data is implemented and operated by Atlassian, not by this app; the app adds the access-control layer on top.

4. Data residency

Secure Fields stores all of its end-user data exclusively in persistent Forge hosted storage. Under Atlassian's Forge data residency program, such apps qualify for PINNED status: app data is hosted in the customer's chosen Atlassian location, and if an admin migrates their Jira instance to a different location, the app's stored data migrates with it. Atlassian manages the hosting, pinning, and migration. Admins can verify the app's residency status in Atlassian Administration's data residency interface.

In-scope End-User Data declaration (required by Atlassian's data residency program): the following app data is in scope for data residency and stored in Forge hosted storage — (a) protected field values, (b) per-field permission configuration, and (c) access audit records (section 9). The app stores no end-user data anywhere else.

5. No external egress ("Runs on Atlassian")

The app's manifest declares no external domains, no remote backends, and no Connect components. All compute and storage are Atlassian-hosted. This is the eligibility bar for Atlassian's Runs on Atlassian program, whose badge is applied automatically on the Marketplace listing — meaning the "nothing leaves Atlassian's infrastructure" claim is verified by Atlassian's own tooling, not just asserted by us. That badge is displayed on our live listing, so you do not have to take our word for it — check Atlassian's page, not ours. Protected values are never sent to the vendor, to analytics services, or to any third party.

Atlassian's own caveat applies and is worth repeating honestly: egress controls constrain where data can go; they are not a substitute for reviewing what access an app requests. Secure Fields requests three scopes — app storage, read-only user information (group membership), and read-only work data (project roles) — and no write scopes against Jira data at all.

6. Accepted tradeoffs — read before buying

These are consequences of the design, not defects. If any of these is a dealbreaker, this product is not the right fit.

• Protected values are not searchable or reportable. No JQL, no filters, no dashboards, no Jira reports can use a protected value — for anyone, including authorized users. A value that Jira could search would be a value Jira stores; that is precisely what this product exists to prevent.
• Protected values are absent from your Jira backups and exports. Jira site exports, backups, and migrations carry only the [secured] marker, because the values were never in Jira. Today that means your Jira backup does not back up protected values (they live in Forge hosted storage, operated by Atlassian). An export-for-backup capability for authorized admins is on the roadmap; until it ships, treat Forge storage as the sole copy and plan accordingly.
• No create-time entry (current release). Secure values are set on an existing issue: save the issue first, then enter the protected value. The field guides users through this. Create-screen support is the top roadmap item.
• Cloned issues do not carry the protected value. Cloning copies the Jira field content — which is only the marker — so a clone has no stored value attached. This fails in the safe direction (no silent duplication of sensitive data).

7. Data lifecycle (current state, stated plainly)

• Protected values persist in Forge hosted storage until overwritten. A user with edit access can overwrite a value at any time.
• Automatic purge on issue deletion is not yet implemented. Deleting an issue currently leaves the stored value orphaned in app storage (unreachable through the app's read path, which is keyed to the issue, but not yet deleted). Automatic purge on issue delete — which is also the right-to-erasure mechanism relevant to GDPR programs — is a committed roadmap item, alongside a documented manual erasure procedure.
• Uninstalling the app removes access to stored values; Forge hosted storage follows Atlassian's published data lifecycle for app storage.

8. Scope of write protection

Jira cannot be used to write arbitrary content into a Secure Text field by any tested path. Direct REST edits (PUT), issue-create payloads (POST), the bulk edit API, and automation rules are all rejected by server-side validation — the API returns an error and nothing is stored. CSV import accepts the field mapping but the value is discarded before it reaches the field: the issue is created and the field stays empty, so nothing leaks (importing admins should note the value is dropped silently rather than rejected with an error). On every tested write path, the Jira field can never hold anything but the inert [secured] marker, however a write is attempted. This was verified empirically on a live Jira Cloud site with authorized and unauthorized accounts, and the checks run as a regression suite.

A small number of paths have not yet been explicitly tested — site-migration tooling (JCMA), JSON import, the legacy REST v2 API, other project templates, and GDPR export; the enforcement is platform-level and is expected to behave identically, and we will extend the verified list as these are checked.

The failure mode is disclosure-safe in any case: anything any write path could place in the Jira field would sit in plain Jira storage and would never be treated as, or mingled with, a protected value — the protected store is written exclusively by the app's backend.

9. Access audit logging

The app keeps an audit trail answering "who accessed this protected value, and when," designed for HIPAA-style access-accounting requirements:

• every successful reveal of a protected value is logged (masked renders expose nothing and are not logged), along with every edit and every permission-rule change;
• each record holds issue, field, actor, action, and time — never the protected value itself;
• rapid repeat reveals by the same user on the same field within a short window are de-duplicated;
• Jira admins can query the log from the app's admin page by time range, issue, field, user, or action.

Audit records live in the same Atlassian-hosted Forge storage as everything else (sections 4–5) and are written only by the app's backend.

10. Compliance positioning — precise wording

Secure Fields is a technical access control designed to support customers' compliance programs — HIPAA, SOC 2, GDPR, ISO 27001 and similar — by keeping designated field values out of Jira's data plane and enforcing least-privilege, deny-by-default access with server-side checks.

To be precise about what that means:

• No software product makes an organization "HIPAA compliant." Compliance is a property of your program — policies, agreements, training, and controls. Secure Fields can serve as one such control (field-level access restriction and access audit records); it is not a certification and we do not claim one.
• Your relationship with Atlassian is unchanged. Whether and how you may store regulated data (e.g., PHI) in Atlassian cloud products — including any Business Associate Agreement or equivalent — is governed by your agreement with Atlassian. See the Atlassian Trust Center for Atlassian's certifications and terms. Secure Fields runs entirely on that same platform and inherits its controls; it neither extends nor replaces them.
• Platform-level protections referenced in this document (encryption, tenant isolation, data residency, physical security) are implemented and operated by Atlassian under the Forge shared responsibility model. The app's own responsibilities — authorization logic, deny-by-default behavior, no value leakage into Jira, logs free of sensitive data — are described in sections 1–2 and are what our verification suite exercises.

11. How to verify our claims yourself

We prefer verifiable claims over trust. On your own site, with a field of this type on an issue you can see:

1. Store a distinctive test value through the field, then fetch GET /rest/api/3/issue/{key}?fields=*all&expand=names — the response contains only [secured], regardless of who asks.
2. Search JQL for the test value — zero results; a field-scoped text search is rejected because the field is not text-indexed.
3. Export the issue to CSV — the column contains [secured].
4. Attempt a REST PUT writing arbitrary text into the field — it is rejected.
5. View the issue as a user outside the field's configured groups/roles — the field renders a masked placeholder.
6. Check the Marketplace listing for the Runs on Atlassian badge — it is displayed there today — and your admin data residency screen for the app's PINNED status.

12. Reporting a security concern

Report suspected vulnerabilities privately to support@inorganicgames.com. Please do not open public issues for security reports. We commit to acknowledging reports promptly and to not taking action against good-faith research.