Recommended Free Tools
To harden a self-managed Atlassian Data Center deployment, keep its software and dependencies supported and patched, restrict network and account access, configure authentication and application permissions separately, monitor activity, and prove that backups can be restored. Atlassian provides secure releases and guidance; the customer remains responsible for the security of its self-managed infrastructure and its operational configuration.
Use this checklist as an audit or change plan. Confirm each control against the exact product, version, identity setup, and infrastructure in your deployment: Atlassian’s configuration and feature support vary by product and release.
1. Prepare an inventory and patch plan
- Inventory the deployment. Record every Atlassian product and version, operating system, software dependency, installed app or plugin, externally reachable endpoint, and system owner. Keep the inventory current when products, versions, or network exposure change.
- Track Atlassian security advisories. Subscribe to security advisory alerts, assess affected products and versions promptly, and schedule fixes according to exposure and risk. Keep products on supported releases; consider Long Term Support (LTS) releases where they suit your upgrade approach. Check Atlassian’s current lifecycle information for the product before deciding whether a version remains supported.
- Patch the surrounding stack. Keep operating systems and software dependencies supported and current as well as the Atlassian application. Include apps and plugins in the review: they add code and access to the deployment, so record who owns each one and whether it is updated.
- Record the baseline. Document security-relevant configuration before changes, upgrades, or migrations. Use that record to verify that intended controls remain in place afterward.
Atlassian’s Data Center security checklist and shared responsibilities guidance, last modified February 23, 2025, describes the customer’s responsibility for securing self-managed infrastructure and configuration. Use current product lifecycle and advisory information when planning work; support status can change.
2. Protect hosts, databases, and network paths
- Limit network exposure. Place services on appropriately private networks. Restrict inbound firewall rules to the application and management traffic the deployment actually needs. Use a VPN for administrative paths where it fits your environment.
- Secure the infrastructure. Restrict physical and virtual server and storage access, and protect stored data with encryption appropriate to your environment. Atlassian’s shared-responsibility guidance does not make Atlassian responsible for customer-managed hardware infrastructure.
- Constrain database access. Limit database connectivity to application hosts and give the application’s database service account only the privileges it needs. Avoid exposing the database to general user or public networks.
- Harden installation and storage permissions. Where practical, install from a secure environment isolated from public networks. Run the application as a dedicated non-root account, restrict access to installation, home, and storage directories, and monitor application binaries for unexpected changes.
- Review controls after infrastructure changes. Check firewall rules, service-account access, directory permissions, and documented configuration after upgrades, migrations, or changes to hosts and storage.
The non-root account, directory-permission, binary-monitoring, and database-account recommendations are covered in Atlassian’s Confluence security best practices, last modified December 10, 2024. Apply product-specific instructions to other Data Center applications rather than assuming every detail is identical.
#1 Best Overall
3. Configure identity, authentication, and authorization
Check product and version support before enabling SAML SSO
Atlassian’s SAML SSO documentation, last modified October 2, 2025, listed these minimum product versions. These are the versions stated on that page at that date, not a guarantee of current support; check the live documentation and your product’s compatibility before deployment.
| Product | Minimum version listed by Atlassian |
|---|---|
| Jira Software Data Center | 8.15 |
| Jira Service Management | 5.15 |
| Bitbucket Data Center | 7.12 |
| Confluence Data Center | 7.12 |
| Bamboo Data Center | 8.1 |
| Crowd | 7.1 |
Keep authentication distinct from application access
- Use a supported identity provider and SAML SSO where it fits the environment. Atlassian identifies providers it tests and says the app should work with an identity provider implementing the SAML 2.0 Web Browser SSO Profile with HTTP POST binding; provider configuration details are not interchangeable.
- Use HTTPS for the application and the identity-provider connection, and configure an HTTPS application base URL.
- Treat SSO as authentication, not authorization. A successful login does not grant access to projects, repositories, spaces, or administrative functions. Configure application access, groups, roles, and permissions separately in the directory or application.
- Before a broad SSO rollout, test the product-specific fallback mechanism and document how authorized administrators can recover access if SSO fails. Atlassian’s documented fallback methods differ by product.
Reduce credential and membership risk
- Where supported, prefer personal access tokens for integrations. Disable basic authentication only when the SSO and token setup, plus integration requirements, allow it; first identify any clients that depend on it.
- Disable accounts promptly when people leave, and limit membership in powerful groups. Do not grant system-administrator permissions to broad groups.
- Keep the number of administrators small. Use separate everyday and administrative accounts where applicable, avoid shared administrator accounts, and do not use easily guessed administrator names or credentials.
4. Restrict and secure administrative access
- Limit who can reach administration surfaces. Restrict administrative interfaces to approved IP addresses through product-supported controls or the reverse proxy. Jira’s websudo IP allowlist is an option for certain superuser operations; confirm the applicable product behavior and configuration rather than treating it as a universal Data Center setting.
- Use secure administrator sessions. In Jira, secure administrator sessions require re-authentication to reach administrative functions and are enabled by default. Atlassian documents a default rolling timeout of 10 minutes for Jira. Check the exact version’s settings and behavior; do not assume Confluence or another application uses the same defaults.
- Protect privileged sessions. Use administrator accounts only for administrative work, end sessions when work is complete, and avoid shared sessions or credentials. Ensure recovery access is documented and protected.
- Consider a web application firewall. A WAF can help address common web attack classes, but tune it for the deployment and test legitimate application and integration traffic. It does not replace patching, access restrictions, or secure configuration.
5. Reduce abuse and monitor the deployment
- Use suitable abuse controls. Consider login CAPTCHA, Fail2Ban, or rate limits where the product and deployment support them. Confirm the feature for the specific product and test its effect on legitimate users, automation, and integrations before enabling it broadly.
- Review audit coverage. Configure audit logs to capture important administrator and user events. Check what the product records and whether the settings meet your investigation and retention needs.
- Protect and review logs. Prevent public access to logs, monitor access logs for unusual activity, and move retained logs to alternate storage if you need a longer investigation history. Restrict access to log storage as well as to the application.
- Reassess installed apps. Include each app’s owner, business need, access, and update status in recurring security reviews. Remove apps that are no longer needed through the applicable product procedure.
6. Back up, restore, and rehearse recovery
- Use regular backups and protect them. Set a schedule appropriate to your recovery needs, store backup files securely and redundantly, and restrict who can access them.
- Choose a backup method that fits an active instance. Atlassian’s security checklist says native database backup tools provide a more secure, consistent, and reliable way to back up and restore active instances. It warns that an XML database backup may be inconsistent if the database changes while the backup is running. Follow the relevant product and database documentation for the supported procedure.
- Test restores. A completed backup job does not prove that the system can be recovered. Perform restore tests and confirm that the restored deployment and required data are usable.
- Recheck after change. Revisit backup arrangements and security controls after major upgrades or migrations, when configuration, storage, and recovery assumptions may have changed.
7. Prepare an incident-response checklist
Write down roles, escalation contacts, decision authority, and recovery steps before an incident. If compromise is suspected, use a documented response process such as this:
Rank #2
- Contain the system. Isolate the affected system from networks or services as appropriate to limit further access. Coordinate containment with the people responsible for the deployment and connected infrastructure.
- Preserve evidence. Preserve relevant logs and other evidence before routine cleanup or rebuild steps remove it. Record response actions and timing.
- Assess accounts and scope. Review user and administrator accounts, determine the suspected scope of access and accessed content, and check repositories for credentials that may have been committed.
- Rotate exposed credentials. Change administrative passwords and rotate other credentials that may have been exposed, including secrets found in repositories or used by affected integrations.
- Recover deliberately. Restore or rebuild from backups as appropriate to the incident and recovery plan. Validate the recovered system before returning it to service.
- Communicate and review. Notify affected stakeholders through the organization’s response process, then conduct a root-cause review and update controls, monitoring, and recovery procedures.
Atlassian’s checklist recommends isolation, evidence preservation, account and log review, credential rotation, recovery from backups where appropriate, stakeholder communication, and root-cause review. The exact containment and notification decisions depend on the organization and incident.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
