Mirth Connect Security & HIPAA Checklist (2026 Edition)

Mirth Connect moves electronic protected health information (ePHI) between clinical systems. That puts every Mirth deployment inside the scope of the HIPAA Security Rule's administrative, physical, and technical safeguards. Getting the safeguards right is not optional — it is the difference between a healthcare integration platform you can defend in an audit and a liability waiting to be found.

This checklist is the one we use on every US healthcare engagement. It is structured so you can take it to a compliance review, a risk assessment, or an internal security team and walk through it line by line. Each section maps controls to HIPAA Security Rule citations and includes the actual configuration — not just the policy language.

If you need these controls implemented quickly, our Mirth helpdesk and integration services teams deploy HIPAA-hardened Mirth environments as a standard offering — BAA included.

1. Why This Checklist Exists

Default Mirth Connect installations are optimized for getting started — not for production. Out of the box you get:

A default admin account with a known password.
Plaintext HTTP administrator access in some configurations.
Derby as the embedded database, unencrypted on disk.
JVM with no audit log integration.
Listener ports that will accept any incoming TCP handshake.

None of that is acceptable for ePHI. The gap between default Mirth and HIPAA-ready Mirth is a couple of weeks of focused engineering. This checklist is what you do in those weeks.

For the broader picture of Mirth Connect in production, see our complete guide to Mirth Connect. For TLS-specific hardening that goes deeper than this checklist, see our companion SSL/TLS hardening guide.

2. HIPAA Security Rule Mapping

The Security Rule (45 CFR Part 164 Subpart C) organizes requirements into three categories. Mirth Connect touches all three, but the technical safeguards carry the heaviest weight.

2.1 Administrative safeguards (§164.308)

Security management process — risk analysis covering every Mirth interface and ePHI data flow.
Workforce security — authorization, supervision, and termination procedures for anyone with Mirth access.
Information access management — role-based access enforced in Mirth's RBAC.
Security awareness and training — integration engineers trained on PHI handling specific to Mirth work.
Security incident procedures — an incident response plan that contemplates Mirth-specific incidents.
Contingency plan — backups, disaster recovery, and emergency operation procedures.

2.2 Physical safeguards (§164.310)

Facility access controls — where the Mirth servers physically live.
Workstation security — laptops used to administer Mirth are managed and encrypted.
Device and media controls — disposal, reuse, and accountability of any storage that held ePHI.

2.3 Technical safeguards (§164.312)

Access control (§164.312(a)) — unique user identification, automatic logoff, encryption and decryption.
Audit controls (§164.312(b)) — hardware, software, and procedural mechanisms that record activity.
Integrity (§164.312(c)) — prevent improper alteration or destruction of ePHI.
Person or entity authentication (§164.312(d)) — verify the identity of users.
Transmission security (§164.312(e)) — technical measures to guard against unauthorized access during transmission.

The rest of this checklist is organized around those technical safeguards, because that is where Mirth configuration lives.

3. Access Controls and RBAC

Access control maps to §164.312(a). Each control below is a hard requirement for a production deployment.

✓No shared admin accounts — each administrator has a unique named account
✓Default "admin" account renamed or disabled after initial setup
✓Strong password policy enforced (12+ chars, complexity, rotation)
✓MFA required for all administrator logins — via SSO/SAML or an external gateway
✓Role-based access control (RBAC) configured — developers, operators, auditors have distinct roles
✓Least-privilege principle applied — no user has more rights than their role requires
✓Terminated-employee access revocation procedure tested at least annually
✓Administrator session timeout configured (30 minutes or less)
✓Failed-login lockout enabled — 5 attempts, then temporary lockout
✓Periodic access review — every 90 days, document who has what role and why

3.1 Configuring RBAC in Mirth

Mirth supports user roles via the Administrator's Settings → Users panel. Define roles that match your org:

Admin — full access. 2–4 named engineers in production.
Operator — can start/stop channels, view dashboards, replay messages; cannot change channel code.
Developer — full access in non-prod only.
Auditor — read-only dashboard and audit log access for compliance staff.

Map each person's responsibilities to a single role. Review the mapping every 90 days as part of your access review procedure.

3.2 SSO and MFA

Mirth does not ship native MFA. For HIPAA-grade deployments, front the Administrator with an identity provider (Okta, Azure AD, Keycloak) and require MFA there. Alternatively, restrict Administrator access to a bastion host that enforces MFA before allowing any inbound session.

4. Encryption in Transit

Transmission security maps to §164.312(e). Every PHI-bearing network flow must be encrypted.

✓TLS 1.2 minimum on all external interfaces — TLS 1.3 preferred where supported
✓Legacy SSLv3, TLS 1.0, and TLS 1.1 explicitly disabled
✓Weak ciphers (RC4, 3DES, export-grade, NULL) explicitly disabled
✓MLLP traffic uses MLLPS (MLLP over TLS) for all inter-organization and cross-network flows
✓HTTPS listener used for Mirth Administrator — plain HTTP admin access disabled
✓Certificates issued by a trusted CA (internal or external) — no self-signed in production
✓Certificate CN/SAN matches the hostname senders connect to
✓Certificate renewal automation in place with 90/60/30/7-day expiry alerts
✓mTLS (mutual TLS) required for high-sensitivity MLLPS interfaces
✓HSTS header enabled on Mirth Administrator HTTPS listener

4.1 Enforce TLS 1.2+ on the Mirth Administrator

# In mirth.properties
https.enabled=true
https.port=8443
http.enabled=false   # Disable plain HTTP

# Enforce TLS 1.2+ in the JVM
-Djdk.tls.server.protocols=TLSv1.2,TLSv1.3
-Dhttps.protocols=TLSv1.2,TLSv1.3

4.2 Test your TLS configuration

# From a client
openssl s_client -connect mirth-host:8443 -tls1_2
openssl s_client -connect mirth-host:8443 -tls1   # Should fail

# Enumerate supported ciphers
nmap --script ssl-enum-ciphers -p 8443 mirth-host

See our SSL/TLS hardening guide for deeper cipher suite selection, mTLS setup, and certificate rotation automation.

5. Encryption at Rest

Encryption at rest applies to the database, backups, keystores, logs, and any archive store where messages land. The checklist:

✓Message store database uses full-disk encryption (LUKS, BitLocker, or cloud provider KMS)
✓Sensitive configuration values (DB passwords, API keys) stored in Mirth's encrypted configuration, not plaintext
✓Keystore and truststore files protected with filesystem ACLs (readable only by Mirth service user)
✓Keystore passwords stored in a secrets manager, not in configuration files
✓Backup artifacts (channel exports, DB dumps) encrypted with a separately-managed key
✓Backup encryption key rotation procedure documented and rehearsed
✓Sensitive log content scrubbed — PHI patterns filtered from log output where possible
✓Swap and temporary storage encrypted on Linux hosts (encrypted swap partitions)
✓Cloud object storage for archived messages uses server-side encryption with customer-managed keys
✓Encrypted and unencrypted tiers clearly labeled — no PHI accidentally lands in an unencrypted tier

5.1 Mirth's configuration encryption

Mirth encrypts sensitive configuration fields (DB passwords, certain channel credentials) using a key stored at conf/mirthkey. Protect this file — whoever reads it can decrypt every stored password.

# Strict filesystem ACL on the encryption key
sudo chmod 600 /opt/mirthconnect/conf/mirthkey
sudo chown mirth:mirth /opt/mirthconnect/conf/mirthkey

# Same for keystore and truststore
sudo chmod 600 /opt/mirthconnect/conf/keystore.jks
sudo chmod 600 /opt/mirthconnect/conf/truststore.jks

5.2 Full-disk encryption for the message store

The PostgreSQL data directory containing the Mirth message store must sit on an encrypted volume. On Linux, LUKS with a key managed by your secrets system. On AWS RDS, enable storage encryption with a customer-managed KMS key. Verify the encryption status on a regular cadence — we check quarterly as part of our operational hygiene runbook.

6. Keystore and Truststore Management

Mirth's keystore holds the private keys used for TLS listeners. The truststore holds the CA certificates Mirth trusts for TLS clients. These files are the crown jewels — compromise of either breaks your encryption story.

6.1 Create a hardened keystore

# Generate a new keystore with a 4096-bit RSA key
keytool -genkeypair -alias mirth-mllps \
  -keyalg RSA -keysize 4096 \
  -validity 365 \
  -keystore /opt/mirthconnect/conf/keystore.jks \
  -storetype JKS \
  -dname "CN=mirth.example.org, O=Example Health, C=US"

Export a certificate signing request (CSR), get it signed by your trusted CA, and import the signed chain back:

keytool -certreq -alias mirth-mllps \
  -keystore /opt/mirthconnect/conf/keystore.jks \
  -file mirth.csr

# After CA returns signed certs, import chain:
keytool -importcert -alias root-ca -file root-ca.pem \
  -keystore /opt/mirthconnect/conf/truststore.jks
keytool -importcert -alias intermediate-ca -file intermediate.pem \
  -keystore /opt/mirthconnect/conf/truststore.jks
keytool -importcert -alias mirth-mllps -file mirth-signed.pem \
  -keystore /opt/mirthconnect/conf/keystore.jks

6.2 Password handling

Keystore password stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager, or equivalent), not in configuration files.
Load the password at service start and pass it via environment variable or Mirth's encrypted config — never check it into version control.
Rotate keystore password annually and after any suspected compromise.

6.3 Certificate inventory and rotation

Maintain a central inventory of every certificate in every keystore across every Mirth instance. Record alias, subject, issuer, expiration date, and business owner. Automate alerts at 90, 60, 30, 7, and 1 day before expiry. Certificate expiration is one of the most common causes of avoidable MLLP outages — see our MLLP connection refused guide for the recovery path when it happens.

7. Audit Logging and Retention

Audit controls map to §164.312(b). The checklist:

✓Mirth audit log enabled — logs every admin action (login, channel change, user change)
✓Audit logs shipped off-host to a SIEM or centralized log system within minutes
✓Log retention policy documented — 6 years for HIPAA-covered data at minimum
✓Log integrity protection — append-only storage or cryptographic signing
✓Administrator access to the log system itself is logged and reviewed
✓Alerts configured for high-risk events — failed logins, role changes, channel exports
✓Security event review cadence defined — daily for high-severity, weekly for trend analysis
✓Log format compatible with downstream tools — JSON structured logging preferred
✓Time synchronization via NTP on every Mirth host — audit log timestamps must agree
✓PHI in logs minimized — error messages redacted of patient identifiers where feasible

7.1 Enable Mirth's audit log

The Mirth audit log records administrator actions — user logins, channel changes, role changes, imports, exports, and service events. Enable it in Settings → Configuration:

Set event logging level to "INFO" or higher.
Enable detailed logging on channel deploy/undeploy events.
Route audit events to a separate log appender that ships off-host.

7.2 Ship logs off-host

Logs stored only on the Mirth host are logs you lose when the host is compromised. Use a log shipper (Filebeat, Vector, Fluent Bit) to send Mirth logs, GC logs, and OS logs to a centralized system:

# Example Filebeat config snippet
filebeat.inputs:
  - type: filestream
    id: mirth-logs
    paths:
      - /opt/mirthconnect/logs/*.log
    fields:
      service: mirth-connect
      environment: production

output.elasticsearch:
  hosts: ["https://siem.internal:9200"]
  ssl.enabled: true
  ssl.certificate_authorities: ["/etc/pki/ca.pem"]

8. API and Administrator Authentication

Mirth exposes a REST API for automation. Treat it with the same care as the Administrator UI.

API served only over HTTPS — plain HTTP access disabled.
API accounts separate from interactive admin accounts; credentials rotated quarterly.
API access restricted by source IP where possible (cloud security groups, host firewall).
API calls logged in the audit log.
No long-lived static credentials in automation — use short-lived tokens where possible.

8.1 Administrator client best practices

Use the Administrator over HTTPS exclusively; browser-based launch only on networks that can reach the server directly.
Do not save Administrator credentials in the client's credential store on shared machines.
Session idle timeout ≤ 30 minutes.
Administrator client version matches server version — mismatched clients sometimes bypass newer protections.

9. Network Segmentation and Firewalls

Strong network posture backstops everything else. If Mirth is exposed to the wrong networks, application-layer controls alone are not enough.

✓Mirth hosts on a dedicated VLAN or subnet — not co-located with general-purpose workloads
✓No direct internet inbound — all external access via VPN, bastion, or controlled gateway
✓Egress restricted — only required downstream destinations allowed out
✓Cloud security groups / firewall rules reviewed quarterly and on every change
✓Change-control process for firewall rules documented and enforced
✓Inbound MLLP ports allowlisted by source CIDR, not open to the world
✓Mirth Administrator port restricted to the admin network segment
✓Separate environments (dev, stage, prod) with no shared connectivity paths
✓Jump host or bastion with MFA for operational access
✓Network intrusion detection covering the Mirth subnet

9.1 Minimum firewall rules for a hardened Mirth host

# Allow MLLPS from specific sender CIDR only
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family="ipv4" source address="10.20.30.0/24" port protocol="tcp" port="6661" accept'

# Allow admin HTTPS from management network only
sudo firewall-cmd --permanent --zone=public \
  --add-rich-rule='rule family="ipv4" source address="10.50.50.0/24" port protocol="tcp" port="8443" accept'

# Deny everything else (default policy)
sudo firewall-cmd --reload

10. Vulnerability Scanning and Patching

HIPAA doesn't mandate a specific patch cadence, but the security management process requirement implies you must have one. Ours:

Monthly — OS security patches applied to all Mirth hosts during a scheduled maintenance window.
Quarterly — Mirth Connect version review; apply point releases, evaluate major version upgrades.
Quarterly — JVM security patches applied. Track OpenJDK / Temurin / Oracle advisories.
Continuous — Authenticated vulnerability scans against Mirth hosts (Tenable, Qualys, or equivalent).
Emergency — Any CVE with CVSS 9+ affecting the JVM or Mirth dependencies triggers an out-of-band patch within 72 hours.

Maintain a version inventory: OS, kernel, JVM, Mirth, PostgreSQL, any third-party JARs used in channel code. Know your exposure before the advisory drops.

11. Incident Response Readiness

HIPAA requires documented security incident procedures. For Mirth, scenarios to plan for:

Credential compromise — an admin account is phished. Rotate all credentials, review recent audit log, pull change history.
Certificate compromise — private key exposed. Revoke, reissue, rotate, notify impacted partners.
Unauthorized channel change — a channel was modified outside change control. Identify actor, scope of change, ePHI touched.
Data exfiltration — evidence of PHI leaving the environment via an unintended path. Forensic preservation, breach assessment.
Ransomware / host compromise — full host recovery from backup, keystore and credential rotation.

Every scenario needs a documented runbook, an identified accountable owner, and a rehearsed playbook. Run tabletop exercises quarterly — we aim to test at least two scenarios per quarter.

Know the Breach Notification Rule timeline: 60 days to notify affected individuals after discovery; specific notification to HHS; media notification in breaches affecting 500+ individuals in a state. Your incident response procedure should include the compliance team in the communication tree from the first hour.

12. BAA Considerations

A Business Associate Agreement (BAA) is required with any third party that creates, receives, maintains, or transmits ePHI on your behalf. For Mirth deployments, that usually includes:

Your cloud provider — AWS, Azure, GCP all offer BAAs for their HIPAA-eligible services. Only use those services.
Your managed service provider — anyone who administers Mirth on your behalf.
Your integration partner — Taction Software signs BAAs for all US healthcare engagements.
Your monitoring and logging vendors — if they see audit logs containing PHI, they need a BAA.
Any SaaS that Mirth integrates with — downstream APIs that receive PHI.

Keep a current list of active BAAs with renewal dates. Review annually. Any new integration that creates a new ePHI flow is a BAA trigger — make sure the compliance team sees every change before it goes live.

For the broader interoperability landscape, see our healthcare interoperability guide and the EHR integration guide.

13. Frequently Asked Questions

Is Mirth Connect HIPAA-compliant out of the box?

No. HIPAA compliance is a property of the deployment, not the software. Mirth Connect gives you the building blocks — TLS, audit logging, user accounts, RBAC — but default installations leave many of them off or weak. A production-grade hardening pass is required before processing PHI. This checklist covers what we do on every deployment.

What HIPAA Security Rule requirements apply to Mirth Connect?

All three safeguard categories apply: administrative (workforce access, training, incident response), physical (server location, media disposal), and technical (access control, audit, integrity, transmission security). Mirth Connect sits squarely in the transmission security and access control requirements, and its audit logs support the audit controls requirement.

Does Mirth Connect need a Business Associate Agreement?

Mirth Connect itself is software — you don't sign a BAA with software. You sign BAAs with the organizations that operate, host, or support it on your behalf. If you host Mirth yourself, your staff is part of your covered entity. If a third party hosts or supports it, you need a BAA with that third party. Taction Software signs BAAs for every US healthcare engagement.

How long do I need to keep Mirth audit logs?

HIPAA requires retention of documentation for six years from the date of creation or the date when it last was in effect, whichever is later. Mirth audit logs fall under that retention requirement. Store them off-host in immutable storage, not just on the Mirth server's disk.

Is plaintext MLLP ever acceptable?

Only on networks where the HIPAA transmission security requirement is satisfied by the network itself — for example, an internal VLAN that is physically segregated and never crosses an untrusted boundary. Any MLLP traffic that crosses an untrusted network (including between data centers, across the public internet, or into a cloud provider) must use MLLPS or run inside a VPN/tunnel.

How do I rotate the Mirth keystore password?

Update the keystore password using keytool -storepasswd -keystore keystore.jks -storepass OLD -new NEW, update the Mirth configuration to reference the new password, then restart Mirth. Test every channel that uses the keystore afterward. Rotate on a fixed cadence (we recommend annually) and immediately on any suspected compromise.

Who should have administrator access to Mirth Connect in production?

The smallest number of people who need it. Typically: 2–4 named senior integration engineers, plus read-only audit access for the compliance team. Everyone else works through change tickets and gets their changes deployed by an admin. Developers have full access only in non-production environments.

How often should I run a security review of Mirth?

A light review every quarter (access review, certificate inventory, log retention) and a deep review annually covering configuration drift, patch level, vulnerability scan results, and tabletop exercises. Every major version upgrade should include a hardening re-validation.

Can I store PHI in channel filter and transformer code?

Strongly discouraged. Channel code is treated as configuration — it is versioned, exported, and often shared across environments. Hard-coded PHI creates a sprawling, hard-to-audit surface. Keep PHI in messages in flight, not in channel definitions. If you need reference data that happens to be a patient identifier, load it from a secured data source at runtime.

What's the fastest way to get a compliant Mirth deployment?

Use this checklist as your gate. Pair it with our Mirth Connect helpdesk service or a hardening engagement — we deploy, configure, document, and hand over a HIPAA-ready Mirth environment, complete with runbooks, audit log pipeline, and monitoring, in 2–4 weeks depending on complexity.

Mirth Connect Security & HIPAA Checklist:2026 Edition

Table of Contents