Security

Entra ID Sync for Assets · sellerkit · Version 1.0, effective 7 September 2026

Where the app runs

The app is built on Atlassian Forge and runs on Atlassian's own infrastructure. We operate no server, no database and no network of our own. There is no host of ours holding your data and no credential of ours that could be stolen to reach your site or your tenant.

What it connects to

Two hosts, and no others. The app declares them in its manifest and Atlassian enforces the list:

Permissions it asks Microsoft for

User.Read.All and Group.Read.All as application permissions, both read-only. The app cannot change anything in your tenant, because it never asks for permission to.

We deliberately do not ask for Directory.Read.All. It is simpler for us and it is what several apps in this category request, and it reads a great deal more than the users and groups an import needs. An administrator is right to refuse it, so we do not ask.

You create the application registration in your own tenant, you grant it those two permissions, and you can revoke it at any time from the Azure portal without touching Jira.

Permissions it asks Jira for

Read and write on Assets objects and schemas, and app storage. Nothing else. It cannot read your work items, your projects or your attachments.

What is stored, and where

Inside your own Atlassian site, in the app's storage:

Directory data is not stored by the app. Users are read from Microsoft Graph, written into your Assets schema, and dropped. The only place a person's details come to rest is your own Assets objects, under your own retention rules.

A run log can name an Entra object ID when explaining why a record was skipped. It holds no names, addresses or contact details.

Credentials

The app never sees a Microsoft password. It does hold the client secret of the application registration you create, because a sync that runs at 02:00 has nobody present to sign in, and that is the only shape of credential Microsoft offers for unattended access.

That secret is written with Forge's encrypted secret store (kvs.setSecret), inside your own Atlassian site. It is encrypted at rest, it is readable only by this app's own backend functions, and there is no code path that returns it to a screen or to us — once saved, the configuration page can tell you which tenant is connected and nothing more. Access tokens obtained with it are stored the same way and expire in an hour.

To end it: press Disconnect in the import configuration, or delete the client secret in the Azure portal. Either one stops the app immediately.

Building and releasing

Every release is deployed through the Forge CLI from a workstation with two-step verification on the Atlassian account. Dependencies are pinned in a lockfile. Only Atlassian's own review and deployment pipeline can put a version in front of your users.

Reporting a vulnerability

Write to globalmatchhub@gmail.com with the words security report in the subject. Please include enough detail to reproduce the problem.

If something happens

If a security problem affects customer data we will contact affected administrators by the email on their Marketplace account within 72 hours of confirming it, describe what happened and what we are doing, and publish a note on this page.