Message Broker Compliance: HIPAA Security Rule, PCI-DSS & SOC 2 for Apache ActiveMQ®

In all three cases, the same question surfaces: what does compliance mean for the message broker specifically? What configurations are required? What evidence must be retained? What does the auditor actually look at?

This guide maps the HIPAA Security Rule, PCI-DSS 4.0, and SOC 2 Trust Services Criteria that are most relevant to Apache ActiveMQ® and other message brokers, translated from regulatory language into specific broker configurations, log retention requirements, access control settings, and the audit evidence that demonstrates compliance. This is not legal advice. It is a technical practitioner’s guide to meeting compliance requirements at the broker layer.

Why the Message Broker Is a Compliance Asset

Enterprise messaging infrastructure is in compliance scope when it touches regulated data, and it often touches regulated data in ways that are not obvious at first assessment.

In-scope scenarios:

• An Apache ActiveMQ® broker routing ePHI (patient identifiers, diagnosis codes, prescription data) between healthcare application components → HIPAA in scope
• A broker in the data flow path for credit card transaction messages (even if it does not store PANs persistently) → PCI-DSS CDE scope
• A broker included in the system boundary for a SOC 2 assessment → SOC 2 control evidence required

Common incorrect assumptions:

• “We don’t store card numbers in Apache ActiveMQ®, so it’s not in PCI scope.” If cardholder data flows through the broker, even transiently in memory, the broker is in the CDE.
• “Messages are just in transit, they’re not stored, so HIPAA doesn’t apply.” HIPAA covers ePHI in transit, not just at rest. A broker transmitting unencrypted ePHI across a network violates the Security Rule.
• “We have TLS, so we’re done.” TLS addresses confidentiality in transit. HIPAA and SOC 2 also require access control (authentication/authorization), audit trails, and availability controls that TLS alone does not provide.

The practical starting point: draw a data flow diagram for regulated data through your system. If a message broker appears on any path where regulated data flows, that broker is in scope and requires documented controls.

HIPAA Security Rule: Applied to Message Brokers

The HIPAA Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards for ePHI. For a message broker handling ePHI, the technical safeguards are the primary focus.

Technical Safeguard 1: Access Control (164.312(a)(1))

Requires unique user identification and automatic logoff. For Apache ActiveMQ®, this means:

<!– activemq.xml — JAAS authentication for unique user identity –> <plugins>   <!– Each system that connects must authenticate with unique credentials –>   <!– Shared credentials (“service_account” used by multiple systems) fail §164.312(a)(1) –>   <jaasAuthenticationPlugin configuration=”activemq”/>   <authorizationPlugin>     <map>       <authorizationMap>         <authorizationEntries>           <!– ePHI queues: restrict to specifically authorized systems –>           <authorizationEntry queue=”phi.notifications.>”             read=”phi-consumers”             write=”phi-producers”             admin=”phi-admins”/>           <!– Block all other access by default –>           <authorizationEntry queue=”>”             read=”admins”             write=”admins”             admin=”admins”/>         </authorizationEntries>       </authorizationMap>     </map>   </authorizationPlugin> </plugins>

Compliance evidence: the JAAS configuration file showing user definitions and the authorizationPlugin showing per-queue access restrictions. Auditors may ask for evidence that each connecting system has unique credentials, not a shared service account.

Technical Safeguard 2: Audit Controls (164.312(b))

Requires hardware, software, and procedural mechanisms to record and examine activity in information systems containing ePHI. Six-year retention is mandatory.

# bin/env (Classic) — enable full audit logging for HIPAA ACTIVEMQ_OPTS=”$ACTIVEMQ_OPTS \   -Dorg.apache.activemq.audit=all” # Produces: ACTIVEMQ_HOME/data/audit.log # Records: JMX operations, queue creates/deletes, user connects/disconnects # etc/log4j2.properties (Artemis) — enable all three audit loggers # audit.base: JMX management operations (queue create, purge, delete) logger.audit_base.name = org.apache.activemq.audit.base logger.audit_base.level = INFO logger.audit_base.appenderRef.audit_log.ref = audit_log_file logger.audit_base.additivity = false # audit.resource: authentication events (login success, login failure, ACL decisions) logger.audit_resource.name = org.apache.activemq.audit.resource logger.audit_resource.level = INFO logger.audit_resource.appenderRef.audit_log.ref = audit_log_file logger.audit_resource.additivity = false # audit.message: message-level operations (produce, consume, browse) # WARNING: high volume on busy brokers — enable selectively on ePHI queues logger.audit_message.name = org.apache.activemq.audit.message logger.audit_message.level = INFO logger.audit_message.appenderRef.audit_log.ref = audit_log_file logger.audit_message.additivity = false

Six-year retention: ship audit logs to a centralized log management system (SIEM, log archive) configured for 6-year retention with write-once or tamper-evident storage. The broker’s local rolling log files alone are insufficient. They rotate and are overwritten.

Compliance evidence: the log4j2.properties configuration showing audit logging enabled; the log retention policy showing 6 years; and sample audit log entries demonstrating that authentication events and management operations are captured.

We covered the complete audit logging configuration for both Apache ActiveMQ® and Apache Artemis™ in our Log Analysis & Diagnostics post.

Technical Safeguard 3: Transmission Security (164.312(e)(1))

Requires encryption or equivalent measures for ePHI transmitted over electronic networks. TLS is the required implementation.

<!– activemq.xml — TLS for ePHI transport (Classic) –> <transportConnectors>   <!– Disable plaintext OpenWire for ePHI-carrying clients –>   <!– <transportConnector name=”openwire” uri=”tcp://0.0.0.0:61616″/> –>   <!– TLS 1.2+ only: ePHI must not transit unencrypted –>   <transportConnector name=”openwire-ssl”     uri=”ssl://0.0.0.0:61617         ?needClientAuth=true         &amp;transport.enabledProtocols=TLSv1.2,TLSv1.3         &amp;transport.enabledCipherSuites=TLS_AES_256_GCM_SHA384,           TLS_CHACHA20_POLY1305_SHA256,           TLS_AES_128_GCM_SHA256″/> </transportConnectors> <sslContext>   <sslContext keyStore=”file:${activemq.conf}/broker.ks”               keyStorePassword=”${ssl.keystore.password}”               trustStore=”file:${activemq.conf}/broker.ts”               trustStorePassword=”${ssl.truststore.password}”/> </sslContext>

The proposed HIPAA Security Rule update (NPRM, January 6, 2025, 90 FR 898) proposes eliminating the “addressable vs. required” distinction. If finalized in 2026 with its proposed 240-day compliance window, encryption in transit becomes an explicit requirement rather than an “addressable” implementation specification. The OCR Director confirmed at HIMSS 2026 that the review is still ongoing; monitor hhs.gov/hipaa/for-professionals/security for finalization.

HIPAA Security Rule Compliance Checklist for ActiveMQ

HIPAA APACHE ACTIVEMQ® COMPLIANCE CHECKLIST

Technical Safeguards:

• □ TLS 1.2+ enabled on all ePHI-carrying transport connectors
• □ TLS 1.0 and 1.1 explicitly disabled
• □ JAAS authentication enabled (unique credentials per connecting system)
• □ authorizationPlugin restricting ePHI queue access to authorized systems only
• □ Audit logging enabled (Classic: -Dorg.apache.activemq.audit=all; Artemis: audit.base, audit.resource, audit.message loggers at INFO)
• □ Audit logs shipped to 6-year retention system (SIEM/log archive)
• □ Audit log integrity protection (tamper-evident or write-once storage)

Administrative Safeguards (broker operator responsibilities):

• □ Business Associate Agreement (BAA) in place with any third-party providing Apache ActiveMQ® support or managed services
• □ Risk assessment performed on broker configuration
• □ Access control policy documented (who can access which queues)
• □ Workforce training on ePHI handling through messaging systems
• □ CVE monitoring and patch procedure documented

Physical Safeguards:

• □ Broker running in a physically secured facility or cloud region with appropriate certifications (SOC 2, ISO 27001)
• □ Workstation access restrictions for broker management consoles

Proposed 2026 HIPAA Update (plan for):

• □ Annual penetration testing on ePHI systems (including broker)
• □ Network segmentation documented and tested
• □ 72-hour system restoration capability (verify HA/DR architecture)

PCI-DSS 4.0: Cardholder Data Environment Controls

PCI-DSS 4.0 became fully effective (all future-dated requirements mandatory) on March 31, 2025. Organizations with Apache ActiveMQ® in the CDE must comply with the updated requirements immediately, not in the next assessment cycle.

Scope Reduction First: Network Segmentation

The most impactful compliance decision for PCI-DSS is keeping the Apache ActiveMQ® broker out of the CDE through network segmentation. A broker that only routes payment confirmation messages (order IDs, status codes, transaction references, not PANs or CVVs) can potentially be scoped out of the CDE if it is proven that actual cardholder data never transits the broker.

If the broker cannot be segmented out of scope, implement these controls:

Requirement 4: Encryption of Cardholder Data in Transit

TLS 1.2 or higher is required for all cardholder data in transit. TLS 1.0 and 1.1 are explicitly prohibited by PCI-DSS 4.0.

<!– Artemis broker.xml — PCI-DSS compliant acceptor –> <acceptors>   <!– No plaintext acceptor for CDE systems –>   <!– All CDE clients must connect via TLS 1.2+ –>   <acceptor name=”cde-ssl”>tcp://0.0.0.0:61617     ?sslEnabled=true     &amp;keyStorePath=/etc/artemis/certs/broker.ks     &amp;keyStorePassword=${ssl.keystore.password}     &amp;trustStorePath=/etc/artemis/certs/broker.ts     &amp;trustStorePassword=${ssl.truststore.password}     &amp;enabledProtocols=TLSv1.2,TLSv1.3     &amp;needClientAuth=true   </acceptor> </acceptors>

Requirement 6: Protect Systems and Software Against Attacks

PCI-DSS 4.0 Requirement 6 requires patching critical vulnerabilities within one month of release. For Apache ActiveMQ®, this maps directly to the patch urgency framework from our Upgrade & Patching Strategy post:

• CVSS ≥ 9.0 (e.g., CVE-2023-46604): emergency, 24-72 hours (stricter than PCI requirement)
• CVSS 7.0-8.9: 7-14 days
• CVSS 4.0-6.9: within one month (aligns with PCI-DSS requirement)

Compliance evidence: a documented vulnerability management procedure for Apache ActiveMQ®; records of CVE monitoring (advisory subscription confirmation); and patch deployment records showing the date each CVE was remediated and the version deployed.

Requirement 7: Restrict Access to System Components

Queue-level access control using the authorizationPlugin ensures only authorized system components access cardholder data queues:

<!– activemq.xml / activemq-security.xml — least-privilege queue access –> <authorizationPlugin>   <map>     <authorizationMap>       <authorizationEntries>         <!– CDE queues: payment systems only –>         <authorizationEntry queue=”payments.>”           read=”payment-consumers”           write=”payment-producers”           admin=”payment-admins”/>         <!– Authorization data: no cross-queue access –>         <authorizationEntry queue=”orders.>”           read=”order-consumers”           write=”order-producers”           admin=”order-admins”/>         <!– Default deny: any queue not explicitly permitted is inaccessible –>         <!– No wildcard grant for non-admin roles –>       </authorizationEntries>       <!– Admin role has no implicit access to CDE queues –>       <tempDestinationAuthorizationEntry>         <tempDestinationAuthorizationEntry           read=”tempAdmins” write=”tempAdmins” admin=”tempAdmins”/>       </tempDestinationAuthorizationEntry>     </authorizationMap>   </map> </authorizationPlugin>

Requirement 8: Identify Users and Authenticate Access

PCI-DSS 4.0 requires multi-factor authentication for all non-console administrative access to the CDE. For Apache ActiveMQ® management:

• The Hawtio web console (port 8161) must require MFA for any CDE-scope administrative login
• JMX management operations must be authenticated (disable unauthenticated JMX, covered in our Security Hardening Guide)
• Each connecting system uses unique service account credentials (not shared accounts)

Requirement 10: Log and Monitor All Access

PCI-DSS requires logging of all access to cardholder data and audit log retention for 12 months (3 months immediately available). For Apache ActiveMQ® in the CDE:

PCI-DSS 4.0 ACTIVEMQ LOGGING REQUIREMENTS:

✓ All authentication events (success and failure)
  → Artemis audit.resource logger captures these

✓ All access to queues containing cardholder data
  → Artemis audit.message logger on payment.> queues

✓ All administrative/management operations
  → Artemis audit.base logger captures JMX operations

✓ Log integrity: log modification detection
  → Forward to SIEM with tamper-evident storage

✓ 12-month retention (3 months immediately accessible)
  → Local rolling logs insufficient; requires log aggregation

SOC 2: Trust Services Criteria for Message Brokers

SOC 2 is principles-based: organizations select which Trust Services Criteria (TSC) to include in scope and then implement controls that satisfy them. The TSC most relevant to an Apache ActiveMQ® broker:

CC6: Logical and Physical Access Controls

CC6 requires that logical access to systems and data is restricted to authorized individuals. For Apache ActiveMQ®, CC6 maps to:

• CC6.1 (logical access controls): JAAS authentication and authorizationPlugin
• CC6.2 (privileged access): administrative access to the broker web console and JMX is restricted and documented
• CC6.3 (access reviews): periodic review of which system accounts have access to which queues, documented and evidenced
• CC6.6 (security events logged): audit logging active and producing evidence of access control operation

SOC 2 evidence for CC6: the auditor will look for operating effectiveness over the audit period, not just that the configuration exists, but that access control is consistently enforced. This means the audit log must show actual authentication events and authorization decisions across the observation period (typically 12 months for Type II).

CC7: System Operations

CC7 requires monitoring for security events and anomalies. For Apache ActiveMQ®:

• CC7.2 (monitoring): continuous monitoring of the broker for unauthorized access attempts, abnormal connection patterns, and resource utilization
• CC7.3 (evaluation of anomalies): alerting when authentication failures spike, when new connections arrive from unexpected IP ranges, or when queue access patterns deviate from baseline
• CC7.4 (response to anomalies): documented incident response procedure for broker security events

This is where purpose-built broker monitoring (rather than generic infrastructure monitoring) provides a compliance advantage. meshIQ Console surfaces per-queue access patterns, connection source monitoring, and authentication failure tracking in ways that generic Prometheus/Grafana dashboards do not expose without custom development.

A1: Availability

If the Availability criterion is in scope, SOC 2 requires evidence that the broker meets its defined uptime commitments:

• HA architecture documented and implemented (covered in our High Availability Architecture Guide)
• Backup and recovery procedures tested and evidenced (covered in our Backup & DR post)
• RTO/RPO commitments defined and tested
• For Type II: evidence of the HA architecture operating effectively over the 12-month observation period (failover events, backup restore tests, maintenance procedures)

SOC 2 Evidence Collection for Apache ActiveMQ®

The distinguishing feature of SOC 2 from HIPAA and PCI-DSS is that it evaluates operating effectiveness over time, not just control design at a point in time. For a SOC 2 Type II audit, the auditor will sample evidence from across the 12-month observation period.

Evidence that SOC 2 auditors commonly request for message broker components:

Control Area	Evidence Required	Source
Authentication configuration	Screenshot of JAAS config; user directory extract	activemq.xml / login.config
Authorization configuration	Screenshot of authorizationPlugin with queue ACLs	activemq.xml / broker.xml
Audit logging active	Sample audit.log entries from multiple periods	audit.log
Access reviews performed	Record of quarterly queue access reviews	Documentation
CVE patching	Patch records for broker CVEs in the period	Change management records
HA architecture	Architecture diagram; failover test evidence	Documentation + test records
Backup tested	Restore test records with dates and outcomes	Documentation
Monitoring active	Screenshots of monitoring dashboards	meshIQ Console / Grafana

Cross-Framework Compliance Control Mapping

The efficiency insight in regulated-industry compliance is that many controls satisfy multiple frameworks simultaneously. Implementing them once and mapping the evidence correctly reduces audit overhead:

ActiveMQ Control	HIPAA Safeguard	PCI-DSS 4.0 Req	SOC 2 Criteria
TLS 1.2+ on all connectors	164.312(e) Transmission Security	Req 4	CC6.7
JAAS authentication	164.312(a) Access Control	Req 8	CC6.1, CC6.2
authorizationPlugin (per-queue ACL)	164.312(a) Access Control	Req 7	CC6.1, CC6.3
Audit logging (all events)	164.312(b) Audit Controls	Req 10	CC6.6, CC7.2
6-year log retention (HIPAA)	164.312(b)	Req 10 (12 months)	CC7.3
HA architecture	Availability safeguard	Req 12 BCP	A1.1, A1.2
CVE patch procedure	Administrative safeguard	Req 6	CC7.1
Network segmentation	Physical/technical safeguard	Req 1 (scope reduction)	CC6.6
Management access audit	164.312(b)	Req 10	CC6.2
Backup and DR procedure	Contingency planning	Req 12.10	A1.3

The TLS, JAAS, and audit logging configuration done for HIPAA satisfies the same requirements for PCI-DSS and SOC 2. The most efficient approach is to implement the most stringent requirement across frameworks (in this case, HIPAA’s 6-year retention is more stringent than PCI-DSS’s 12-month requirement) and use that as the baseline.

The HIPAA Security Rule Update: What’s Changing in 2026

The most significant development in HIPAA compliance for messaging systems in 2026 is the proposed Security Rule update. The OCR published an NPRM (Notice of Proposed Rulemaking) on January 6, 2025 (90 FR 898), and OCR Director Paula Stannard confirmed at HIMSS 2026 that review is ongoing, with the Trump administration potentially reshaping the final rule. Regardless of exact final form, the proposed changes with near-universal commenter support include:

1. Encryption becomes mandatory (not “addressable”): the “addressable implementation specification” category is eliminated. Encryption in transit and at rest for ePHI becomes a mandatory requirement. For Apache ActiveMQ®: TLS on all ePHI-carrying connectors transitions from “strongly recommended” to “required.”

2. Explicit network segmentation requirement: isolating ePHI systems from non-ePHI systems is proposed as a mandatory requirement. This directly affects Apache ActiveMQ® topology: a broker handling ePHI and non-ePHI traffic on the same instance may need to be separated into distinct deployments.

3. Annual penetration testing: all ePHI systems, including messaging infrastructure, must be penetration tested annually under the proposed rule. For Apache ActiveMQ® in HA or multi-DC configurations, penetration testing scope includes broker management interfaces, transport connectors, and inter-broker links.

4. 72-hour restoration target: covered entities must be able to restore ePHI system access within 72 hours of a failure. For an Apache ActiveMQ® broker handling ePHI, this maps to the HA and DR architecture requirements: the broker must fail over within 72 hours with data intact. Most HA configurations achieve this in minutes; the concern is cold standby DR scenarios where KahaDB replay may extend startup time.

Planning recommendation: organizations currently relying on “addressable” HIPAA specifications as justification for not encrypting should assume encryption will become mandatory and configure TLS now. The control implementation cost today is far lower than emergency implementation under a compliance deadline.

Compliance Is Configuration Plus Evidence Plus Process

Running Apache ActiveMQ® in a regulated environment is achievable: the broker’s TLS, JAAS, authorizationPlugin, and audit logging capabilities are mature and production-tested across thousands of healthcare, financial services, and government deployments. The compliance requirements map cleanly to broker configurations that are well-documented and reproducible.

What separates a compliant deployment from a non-compliant one is not exotic technology. It is the combination of correct configuration, continuous monitoring to demonstrate operating effectiveness, and documented evidence that will survive an auditor’s scrutiny. The cross-framework control mapping in this guide ensures that the configuration work done once satisfies multiple frameworks, and the evidence collection process is built into ongoing operations rather than assembled under audit pressure.

We’ll cover the event-driven architecture patterns that make these regulated-industry messaging deployments most effective in our next post in this series.

Get your Apache ActiveMQ® compliance configuration reviewed by our team → Request a Compliance Review

Frequently Asked Questions

Q: Is Apache ActiveMQ® HIPAA compliant? 

Apache ActiveMQ® can be deployed in a HIPAA-compliant architecture when configured with TLS 1.2+ for all connections, JAAS authentication with unique credentials per system, per-queue access control via authorizationPlugin, and 6-year audit log retention. There is no HIPAA certification for software. Compliance is a property of the deployment configuration and operational procedures.

Q: Does Apache ActiveMQ® need to be PCI-DSS compliant when handling payment card data? 

If Apache ActiveMQ® is in the data flow path for cardholder data (even transiently), it is in the Cardholder Data Environment and subject to PCI-DSS 4.0. Key requirements: TLS 1.2+ (Req 4), monthly patching for high-risk CVEs (Req 6), per-queue access control (Req 7), JAAS authentication (Req 8), audit logging with 12-month retention (Req 10). Network segmentation to remove the broker from the CDE is the most effective scope-reduction strategy.

Q: What audit log retention does HIPAA require? 

Six years from the date of creation or last effective date. Audit logs must be retained in a tamper-evident or write-once system. Default Apache ActiveMQ® rolling log files are insufficient. Logs must be shipped to a log management system with 6-year retention configured.

Q: What does SOC 2 require from an enterprise message broker? 

Depends on which Trust Services Criteria are in scope. Typically: CC6 (authentication, authorization, access logging), CC7 (monitoring and anomaly detection), and A1 (availability/HA) if availability is in scope. SOC 2 Type II evaluates operating effectiveness over a 12-month period. Evidence must demonstrate consistent control operation, not just correct configuration.

Q: Does the 2025/2026 HIPAA Security Rule update affect messaging systems? 

Yes, if finalized. The OCR NPRM proposes making encryption mandatory (eliminating “addressable” category), explicit network segmentation requirements, annual penetration testing for ePHI systems, and 72-hour restoration targets. Plan for compliance now: implementing these controls before the rule is finalized costs far less than emergency implementation under a deadline.