The clock is not yours to set
| Date | What Atlassian has announced |
|---|---|
| 30 March 2026 | New customers can no longer buy Data Center subscriptions or Data Center Marketplace apps. |
| 30 March 2028 | Existing customers can no longer buy any new Data Center Marketplace app, or expand the licences they already hold. |
| 28 March 2029 | Data Center subscriptions and their Marketplace apps expire. Those environments become read-only. |
Every Jira Data Center security app on the Atlassian Marketplace expires with the platform. Sensitive Data Scanner is not a Marketplace app. It runs beside Jira rather than inside it, so neither the purchase cutoff nor the expiry applies to it.
Why scan from outside Jira
Nothing to install, nothing extra to migrate
An app installed into the instance you are about to migrate is one more app on your compatibility assessment, and one more change request. This adds nothing to either. It talks to Jira over the REST API with a service account that holds Browse Projects and nothing else.
It cannot change what it examines
The scanner issues no writes of any kind - no edits, no comments, no deletions, no redaction, no field updates. It installs no plugin and never touches the Jira database. The tool that produced your findings had no ability to alter the system they came from.
It outlives the instance
Findings, review decisions and the audit trail live in your own database, outside Jira and under your own backup policy. They do not disappear when the Data Center instance is decommissioned.
Built so the findings hold up under review
Raw values are never stored, exported or displayed
A finding keeps two things: a keyed HMAC-SHA256 fingerprint that recognises the same value across scans, and a source locator. There is no excerpt of any kind - not a masked one, not a truncated one. Nothing derived from the matched text is written to the database, a log, an export or the screen. To read the value you follow the link into Jira, where it already lives.
Swiss identifiers, validated not guessed
AHV/AVS numbers must carry the 756 prefix and a valid EAN-13 check digit. QR references must satisfy the recursive Modulo-10 check. QR-IBANs must carry a QR-IID in the reserved range. A value that fails its check digit is dropped outright and never becomes a finding - so the report you hand over is short enough to act on.
Inside attachments, with the gaps named
The detection rules read the text inside PDF, Word, Excel, PowerPoint, OpenDocument, mail and one level of archive. The format is decided from the file bytes, never from the media type Jira reports, so a mislabelled upload is still read. Extracted text stays in memory and is discarded once the rules have run.
Every consequential action is audited
Configuration changes, connection changes, licence uploads, scan starts, review decisions, suppressions, rule changes and rollbacks, exports and report runs - each with actor, timestamp, target and sanitised metadata. Audit entries cannot be edited through the UI.
Runs in a network with no internet
A Docker container in your infrastructure, sign-in through your own Keycloak or OIDC provider, and licence validation against a public key compiled into the application. No phone-home, no telemetry, no external AI service. The only outbound connections are to your Jira, your identity provider, your database and your SMTP server.
Repeatable, not a one-off script
Immutable scan configurations, cron-scheduled runs, pause and resume, and your own regex rules tested before they go live. Findings carry forward across scans, so a decision made once stays made and the second scan shows you what changed.
How it works
1. Connect
Point the container at your Jira Data Center with a service account that has Browse Projects. A connection test verifies reachability, version and permissions before anything is read.
2. Scan
Choose projects, fields, comments and optionally attachments, set performance limits so Jira stays responsive, and start a read-only run. Pause and resume it whenever you need the capacity back.
3. Review and evidence
Work through the findings, classify or suppress them with a recorded reason, and export the result. What you keep is a reviewed record of what was in the instance and what you decided about it.
What it does not do
A scanner that hides its blind spots is worse than one that names them. These are the current limits, in the same words we use in the documentation.
- No OCR. Text inside screenshots, images and scanned PDFs without a text layer is not read. Image attachments are reported as an unsupported format rather than quietly passed over, and every attachment file name is checked against the rules regardless.
- No remediation. The scanner never edits, redacts or deletes anything in Jira. That is the point of it, and it means the cleanup is yours to carry out.
- Archives are opened one level deep. A zip inside a zip is not opened; the rest of that archive is still scanned rather than discarded.
- Skipped attachments are counted separately from failures, with a documented reason for each category - unsupported, encrypted, too large, corrupt, timed out, or deleted mid-scan. A scan that skips attachments still completes.
- Jira Data Center and Server only. There is no Jira Cloud connector.
See a real scan before you talk to us
The self-service evaluation runs for five days and scans up to 1,000 issues per run without reading attachment contents. It is self-hosted, so we never see your instance, your findings or that you tried it.