How to Restrict Jira Attachments to Specific Users

There is no setting in Jira that restricts a single attachment to a single group. That is the honest starting point, and knowing it saves a lot of time hunting through permission schemes for an option that does not exist.

What follows are the approaches that do work, in order of effort.

First, confirm what you are actually trying to do

Three different problems get described as “restricting attachments”, and they have different answers:

Nobody outside a group should see the file, but everyone should see the work. This is the common one, and native Jira cannot do it.
Nobody outside a group should see any of this work. Native Jira handles this well with project permissions.
People should see the file exists but not open it. Native Jira cannot do this at all, and neither can most apps. Visibility and download are the same permission in practice.

Option 1: separate the work by project

Effort: low. Works when the audience for the work and the audience for the files are the same group.

Create a project (a space, on Jira Cloud) for the sensitive work.
Give it its own permission scheme rather than sharing one with other projects. Sharing a scheme is the mistake that causes this to silently stop working later.
Under Project settings then Permissions, set Browse Projects to only the group that should have access.
Move the sensitive items into that project.
Confirm with a test account that is outside the group. Do not skip this. Permission schemes inherit in ways that are easy to misread.

The catch: everyone excluded also loses the work tracking. If interviewers need to see the hiring progress but not the salary expectations, this does not solve your problem.

Option 2: keep the file outside Jira

Effort: low to set up, ongoing to maintain.

Put the document in a system with real file permissions and link to it from the item.

You get proper access control and version history. You also take on two permission models that drift apart, links that break when folders move, and readers who hit a request-access screen. It is a legitimate choice, but it is a trade rather than a fix, and the audit trail for the work now lives in a different place from the audit trail for the document.

Option 3: an access-controlled attachment area inside Jira

Effort: moderate, one-time. Works when the two audiences genuinely differ.

This adds a second attachment panel to the item, visible only to a configured list of users. The item stays open to the team, the files inside the panel do not.

Using Document Vault as the worked example:

Install the app and open the Admin Document Vault configuration page.
Set the groups and roles that get full access: view, upload, edit, and delete. You can grant this to user groups, project roles, users named in single or multi-user custom fields, users in single or multi-group custom fields, or to the item’s Reporter, Assignee, or Creator.
Set the groups and roles that get read-only access, which on Data Center is user groups and project roles.
Choose where the panel appears, either where Jira attachments normally sit or as an activity tab. This is under Document Vault Position in the Issue Screen in the General Config tab.
Optionally set file extension filtering to control what can be uploaded.
Test with an account outside every configured group. It should see no panel and no file names.

Users outside the access list see nothing at all, which matters more than it sounds. A file name like termination-letter-draft.pdf leaks the situation even if nobody can open the file.

Two limitations to know before you commit:

Access applies to the Vault as a whole, not per file. You are separating “who sees the work” from “who sees the documents”, not setting a different list for each document.
Version history is on Project Documents, not on item attachments. If per-file versioning is your main requirement, check that distinction against your use case.

On Jira Cloud the app is built on Atlassian Forge, so files stay inside your Atlassian instance, with a 50 MB per-file limit.

Securing a file that is already exposed

If a sensitive file is already attached to an item a wide audience can see, changing permissions does not retroactively help. You need to:

Delete the attachment from the item. This is the only way to remove access from people who currently have it.
Check whether it has already been downloaded, if your Jira version’s audit log covers that.
Re-upload it somewhere access-controlled.
Consider whether the exposure itself needs reporting, which for personal or financial data it sometimes does.

A quick checklist before you pick

Do the people who need the work tracking and the people who need the files differ? If no, Option 1 is enough.
Does anything you attach contain personal, financial, or contractual data?
Would you need to prove, later, who could have opened a file?
Does the file name itself reveal something sensitive?
Will access follow group membership automatically, or does it depend on someone maintaining a list?

Frequently asked questions

Can I restrict a Jira attachment to one group? Not with native Jira. There is no per-attachment permission. The practical options are to move the work into a project whose permission scheme only that group can access, or to add an app that provides a separate attachment area with its own access list.

Does restricting the issue also restrict the attachment? Yes, but it restricts everything else too. Anyone who loses access to the issue or work item loses the work tracking along with the file, which is usually not what you want.

How do I stop people downloading Jira attachments? You cannot separate viewing from downloading in native Jira. If a user can see the item, they can download its files. The only way to prevent download is to prevent visibility, which means the file must not be a native attachment on an item they can see.

What is the fastest way to secure an existing attachment? Delete it from the item and re-upload it somewhere access-controlled. Deleting the attachment is the only way to remove access from people who already have it, and it is worth checking whether it has already been downloaded.

Start Document Vault free trial ↗ Document Vault user guide →