Having recently completed a formal evaluation for a client in the financial services sector, I was tasked with architecting a zero-trust access model for their sensitive accounting and trading applications distributed across AWS, Azure, and a private data center. The core requirement was a single control plane for just-in-time, credential-less access to database clusters (PostgreSQL, Microsoft SQL Server) and legacy SSH bastions, with immutable audit logs for compliance (SOX, GDPR).
The shortlist, after initial vendor scoring, came down to HashiCorp Boundary and StrongDM. My methodology involved a two-week, side-by-side proof-of-concept structured around five core operational pillars:
* **Deployment and Administrative Overhead:** Boundary, being open-source with a self-managed model, required provisioning and maintaining its own worker nodes across each cloud. StrongDM’s fully managed control plane eliminated this infrastructure tax but introduced a recurring cost variable.
* **Target Discovery and Session Orchestration:** Boundary operates on a declarative model where targets (e.g., a database endpoint) are explicitly defined in HCL and managed via Terraform. StrongDM utilizes a dynamic discovery agent that automatically inventories network-accessible services, which reduced initial configuration but required careful scoping of the agent's permissions.
* **Identity Federation and Justification Workflow:** Both platforms integrated cleanly with our existing Okta instance for user authentication. However, StrongDM’s native support for access requests and time-bound approvals within its UI provided a more polished workflow out-of-the-box. Achieving similar in Boundary required integrating its API with a separate ticketing system (ServiceNow, in our case).
* **Protocol Depth and Credential Brokering:** For PostgreSQL, both solutions performed admirably, brokering ephemeral certificates. A key differentiator emerged with Microsoft SQL Server, where StrongDM’s proxy handled native Windows Authentication (Kerberos) delegation transparently. Simulating this with Boundary would have required custom development around its plugin framework.
* **Audit Log Fidelity and Extraction:** Boundary logs all session data (including recorded SSH) to its own storage, which then must be forwarded to a SIEM. StrongDM streams structured audit logs directly to an S3 bucket or Splunk, which the compliance team favored for its immutability and ease of ingestion.
The financial calculus became intriguing. Boundary’s open-source core presents a lower apparent entry cost, but the total cost of ownership must factor in the engineering hours for initial cluster setup, ongoing worker scaling, and developing any missing protocol logic. StrongDM’s per-user pricing is higher, yet it bundles the management overhead into the fee.
My preliminary conclusion leans toward StrongDM for this specific multi-cloud finance use case, primarily due to its managed service model, broader native protocol support for Windows-based assets, and the compliance team’s preference for its audit log pipeline. However, I am keen to hear from this community on long-term operational experiences.
Has anyone run a similar comparison in a regulated environment? I am particularly interested in:
* Real-world performance observations when scaling to thousands of concurrent sessions during peak trading hours.
* Experiences with automating target onboarding via Terraform for both platforms, especially when dealing with ephemeral Kubernetes workloads.
* The practical implications of Boundary’s requirement for a direct network path from workers to targets versus StrongDM’s relay architecture.