SailPoint supports IdentityIQ. Who supports the ActiveMQ broker underneath it?
Since IdentityIQ 8.4, an Apache ActiveMQ message broker is part of your identity platform, and SailPoint's own installation guidance points you toward running it as an external broker. That broker is now yours to patch, secure, and keep available. HYTE provides the production support behind it.
24×7 & Business-Hours Packages · Unlimited Support Cases · Messaging Specialists, Not Generalists
You upgraded an identity platform and inherited a message broker
You did not choose to run Apache ActiveMQ. SailPoint introduced the requirement in 8.4 and recommends an external broker, which puts it on your infrastructure.
-
IdentityIQ 8.4 makes a broker mandatory
The Data Extract and Access History features require a message broker. IdentityIQ ships an embedded ActiveMQ broker that starts by default and listens on port 61616.
-
SailPoint recommends an external broker
The 8.4 installation guide describes disabling the embedded broker service and using an external ActiveMQ broker as best practice, citing better administration and tracking. Community threads also report the embedded broker failing to start after restarts and configuration changes, and many teams moved to an external broker for that reason.
-
You reconfigure the connection
Moving off the embedded broker means updating the ClientConnectionString in the MessageBusConfiguration object and standing up a broker that must be running before the application server starts.
-
You own the broker now
SailPoint supports IdentityIQ, and the broker beside it sits outside that boundary. Apache ActiveMQ is community software with no vendor behind it, so the production broker in your identity plane belongs to your team. HYTE supports that layer.
The dependency that gets attention at 2 a.m.
With messaging enabled, the IdentityIQ application server checks the broker connection at startup. If the check fails, the application server does not start. Provisioning, access certifications, and joiner-mover-leaver processing stall until you bring the broker back. A broker outage becomes an identity platform outage, and because the broker sits outside SailPoint's scope, the ticket stays on your desk.
The code running your broker. We help maintain it.
HYTE is not a support shop that learned ActiveMQ from the outside. Our engineers commit code upstream to Apache ActiveMQ, and our lineage with the project reaches back to its earliest production deployments roughly two decades ago.
That changes what support means for the broker under your identity platform. When a root cause lives in the broker itself, we can carry the fix upstream so it lands in the project for good, and your deployment stays on a supported path instead of drifting onto a private fork.
Root-cause depth
Answers grounded in how the broker is built, not in what a knowledge base article says about it.
Fixes that stick
Issues resolved in your environment and, where appropriate, contributed back upstream.
A supported path
Version and architecture guidance that keeps your deployment aligned with the Apache ActiveMQ project.
Auditors flag unowned brokers in the identity plane
Security exposure
ActiveMQ requires active patching, and its CVE history includes advisories that saw wide exploitation, among them CVE-2023-46604. A stale broker version inside your identity infrastructure is a high-severity audit finding. Until you contract it out, your team owns version currency and CVE response.
Configuration burden
TLS between IdentityIQ and the broker, keystores, transport connectors, memory tuning, persistence, and failover sit outside the scope of SailPoint's installation documentation, which covers the IdentityIQ side of the connection. Leave any of them at defaults and production load will find the weak spot for you.
No one on staff owns it
IAM teams are not messaging teams. Hiring a middleware administrator to babysit one broker is hard to justify. A support contract with a messaging specialist is the economical answer, and the accountable one.
Three desks where this broker shows up
01IdentityIQ Administrators
You own the application and inherited the broker with it. When IdentityIQ will not start and the issue turns out to sit below SailPoint's support boundary, HYTE is the number to call for that layer.
02Middleware & Infrastructure
The IAM team handed you an ActiveMQ instance. HYTE brings patch cadence, upgrade paths, monitoring guidance, and an escalation path staffed by people who work on the broker's code.
03CISO & IT Risk
An open-source broker in the identity plane needs an accountable owner for CVE response and hardening. A support contract turns an audit exposure into a managed control.
Support for the broker under IdentityIQ
Production support
Defined response commitments and unlimited support cases on subscription packages.
Upgrades & CVE patching
Version upgrades and security remediation planned around your change calendar.
SSL/TLS hardening
Configuration review for the IdentityIQ connection: transport security, keystores, authentication, and authorization.
High availability & failover
Design and validation so a broker failure does not take IdentityIQ with it.
Embedded-to-external broker migration
Execution of the externalization SailPoint's installation guide describes as best practice, from broker build-out through ClientConnectionString cutover. Talk through a migration →
8.5 removed the requirement. You may still be running the broker.
IdentityIQ 8.5 removes the ActiveMQ dependency for Access History and Data Extract. Teams that stood up an external broker for 8.4 tend to keep it, either through the upgrade window or as shared messaging infrastructure for other integrations. HYTE supports both paths: keep the broker and run it well, or plan a clean decommission without surprises.
Coverage sized to your deployment
Single Incident
- Support for 1 ActiveMQ incident
- 9×5 ET via HYTE support ticket
- Ideal for a one-off fire drill
Starter Support
- Unlimited tickets via HYTE Portal
- 9×5 ET availability
- Platform management tools
- Up to 3 ActiveMQ servers
Pro Support
- Everything in Starter
- 3 years at discounted pricing
- Platform management tools
- Up to 3 ActiveMQ servers
Enterprise Support
- 24×7 coverage options
- Tailored to your environment
- Built for regulated enterprises
- Same-day price quote
Pricing shown reflects HYTE's published ActiveMQ Support packages. Visit hyte.io/activemq-support for current terms.
Frequently Asked Questions
Does SailPoint support ActiveMQ?
Not the broker itself. SailPoint supports IdentityIQ, and the Apache ActiveMQ broker that 8.4 requires, embedded or external, sits outside that support boundary. Apache ActiveMQ is community-maintained software, so the broker needs an owner on the customer side or a commercial support agreement.
Why won't IdentityIQ start after upgrading to 8.4?
With messaging enabled, the application server checks the message broker connection at startup and will not start if the check fails. Confirm the broker is running, reachable on its configured port, and matches the ClientConnectionString in the MessageBusConfiguration object. Community threads document the embedded broker failing to start after restarts and configuration changes.
Should I use the embedded or the external broker with IdentityIQ?
SailPoint's 8.4 installation guide describes disabling the embedded broker and using an external ActiveMQ broker as best practice, citing better administration and tracking. An external broker also isolates the messaging layer for independent patching, monitoring, and high availability.
Who patches the ActiveMQ broker used by IdentityIQ?
The customer does. Broker version upgrades and CVE remediation sit outside SailPoint's support boundary, and the Apache project publishes releases and advisories rather than operating brokers for users. Assign an owner for version currency, or contract the work to a messaging support vendor.
How is the connection between IdentityIQ and the broker secured?
Through TLS for client-to-broker traffic, keystores on both sides, client authentication, and authorization on queues and topics. SailPoint documentation describes the IdentityIQ side of the connection; the broker side is standard ActiveMQ configuration work.
We moved to IdentityIQ 8.5. Do we still need the broker?
The 8.5 release removes the ActiveMQ dependency for Access History and Data Extract. Whether you keep the broker depends on what else came to rely on it. Verify nothing still depends on the broker before you decommission it, or keep it as shared messaging infrastructure.
Is it possible to run this broker in containers or on Kubernetes?
Yes. ActiveMQ versions 6.x and 5.x run well in containers and on Kubernetes with the right architecture for persistence, networking, and failover. Many teams externalize the IdentityIQ broker onto the same container platform that runs the rest of their infrastructure.
We are planning our 8.4 upgrade. When should the broker be stood up?
Before the application server starts in the target environment. With messaging enabled, IdentityIQ checks the broker connection at startup, so a reachable broker and a correct ClientConnectionString are prerequisites for the upgrade rather than follow-up work. Teams that plan the broker alongside the upgrade avoid discovering the dependency during a cutover window.
How do we get support for the broker under IdentityIQ?
A 15-minute conversation with a Messaging Platform Architect is enough to size an IdentityIQ broker footprint. HYTE publishes ActiveMQ support packages from single incidents to enterprise subscriptions, with a same-day quote available for custom coverage.
SailPoint and IdentityIQ are trademarks of SailPoint Technologies, Inc. HYTE Technologies is not affiliated with SailPoint.
Put support behind the broker your identity platform depends on
SailPoint stands behind the application. HYTE stands behind the broker it depends on. One short call is enough to size your environment and price the coverage.
Discuss Support Options → Schedule a 15-min Call