--- title: "Message Broker Compliance: HIPAA Security Rule, PCI-DSS & SOC 2 for Apache ActiveMQ®" date: 2026-08-14 author: "TheFrameGuy" featured_image: "https://www.meshiq.com/wp-content/uploads/blog_activeMQ-message-broker-compliance_08212026.jpg" categories: - name: "Apache ActiveMQ®" url: "/sort-by/active-mq.md" - name: "Middleware Optimization" url: "/sort-by/middleware-optimization.md" - name: "MQ" url: "/sort-by/mq.md" tags: - name: "devops" url: "/sort-by/tag/devops.md" - name: "monitoring" url: "/sort-by/tag/monitoring.md" - name: "Observability" url: "/sort-by/tag/observability.md" --- # 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**](https://www.meshiq.com/blog/activemq-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](https://www.meshiq.com/blog/activemq-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](https://www.meshiq.com/blog/activemq-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 ## ****Configuring Apache ActiveMQ®**** ****for PCI-DSS or HIPAA Compliance?**** Regulated industry compliance configurations require precision: an incorrect TLS cipher, a missing audit logger, or an overpermissive authorizationPlugin can result in a failed QSA assessment or a compliance gap finding. meshIQ’s team has configured Apache ActiveMQ® for regulated environments including financial services, healthcare, and government. [****************Request a Compliance Configuration Review****************](https://www.meshiq.com/solutions/apache-activemq/enterprise-support/) ## 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](https://www.meshiq.com/blog/activemq-high-availability-architecture/)) - Backup and recovery procedures tested and evidenced (covered in our [Backup & DR](https://www.meshiq.com/blog/activemq-backup-disaster-recovery/) 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 configurationScreenshot of JAAS config; user directory extractactivemq.xml / login.configAuthorization configurationScreenshot of authorizationPlugin with queue ACLsactivemq.xml / broker.xmlAudit logging activeSample audit.log entries from multiple periodsaudit.logAccess reviews performedRecord of quarterly queue access reviewsDocumentationCVE patchingPatch records for broker CVEs in the periodChange management recordsHA architectureArchitecture diagram; failover test evidenceDocumentation + test recordsBackup testedRestore test records with dates and outcomesDocumentationMonitoring activeScreenshots of monitoring dashboardsmeshIQ 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 connectors164.312(e) Transmission SecurityReq 4CC6.7JAAS authentication164.312(a) Access ControlReq 8CC6.1, CC6.2authorizationPlugin (per-queue ACL)164.312(a) Access ControlReq 7CC6.1, CC6.3Audit logging (all events)164.312(b) Audit ControlsReq 10CC6.6, CC7.26-year log retention (HIPAA)164.312(b)Req 10 (12 months)CC7.3HA architectureAvailability safeguardReq 12 BCPA1.1, A1.2CVE patch procedureAdministrative safeguardReq 6CC7.1Network segmentationPhysical/technical safeguardReq 1 (scope reduction)CC6.6Management access audit164.312(b)Req 10CC6.2Backup and DR procedureContingency planningReq 12.10A1.3The 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. ## **Continuous Compliance Evidence Collection for Apache ActiveMQ®** meshIQ Console provides the monitoring, audit log visibility, and access pattern tracking that SOC 2 auditors look for, converting the broker’s operational data into the continuous evidence required for Type II compliance. No manual evidence collection during the audit period; Console maintains it automatically. [**************See It in Action**************](https://www.meshiq.com/request-a-demo/) ## 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**](https://www.meshiq.com/solutions/apache-activemq/) ## 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.