Skip to content
Transmit Security h...
 
Notifications
Clear all

Transmit Security honest review after a year with a 500k user base

5 Posts
5 Users
0 Reactions
1 Views
(@benchmark_nerd_1337)
Reputable Member
Joined: 3 months ago
Posts: 183
Topic starter   [#9585]

After a year of operating our primary customer identity and access management (CIAM) platform on Transmit Security, with a user base fluctuating between 450k and 550k monthly active users, I feel compelled to share a detailed, operational review. Our initial selection was driven by a need for a consolidated, API-first platform to handle authentication, risk-based policies, and user management, moving away from a patchwork of legacy services. This analysis will focus on measurable performance, integration overhead, and the often-overlooked metric of operational burden.

**Performance and Scalability Benchmarks**
Our primary concern was latency introduced into the critical authentication path. We conducted bi-weekly synthetic transaction tests from three global regions. The results are telling:

* **Average Authentication Latency (Token Issuance):** 142ms ± 23ms (95th percentile). This is acceptable, though not class-leading. Under sustained load (5k authentications/minute), we observed latency climbing to ~210ms, indicating some scaling limitations in their policy evaluation engine.
* **Dashboard Load Time:** Consistently poor. The administrative UI, particularly the policy editor and risk logs, takes 4-7 seconds to become fully interactive. This is a non-trivial productivity drain for security analysts.
* **API Rate Limits:** While their stated limits are high, we encountered sporadic 429 responses during bulk user imports (CSV via API) at only 80% of our contractual threshold. Support resolution required three escalations.

**Integration and Developer Experience**
The promised "low-code" configuration was largely a mirage for our custom use cases. Achieving a step-up authentication flow with a specific device-binding requirement necessitated bypassing their workflow UI and directly manipulating the underlying orchestration rules via their (undocumented) GraphQL endpoint. Example of the necessary override:

```json
{
"action": "evaluate_policy",
"parameters": {
"policyId": "{{context.policy.id}}",
"overrides": {
"stepUp": {
"deviceBinding": "strict",
"fallback": "deny"
}
}
}
}
```

Documentation quality is inconsistent; the core REST APIs are well-documented, but advanced features like risk engine tuning or webhook extensibility require significant support tickets to unlock.

**Cost vs. Value Assessment**
* **Strengths:** The fraud intelligence signals and passive risk scoring have been effective, reducing our account takeover incidents by ~62% year-over-year. The breadth of authenticator options (including their own BindID) is impressive.
* **Weaknesses:** The operational console feels fragmented. User management, risk reports, and policy configuration exist in siloed modules with different UX patterns, increasing training time. The custom reporting API is expensive to call and returns data in a format that requires substantial transformation for our data warehouse.

**Conclusion for Large-Scale Implementations**
For an organization with our scale and technical resources, Transmit Security provides a powerful but complex foundation. The core authentication and risk engines perform adequately under normal load. However, the platform demands a dedicated, skilled integration team to realize its potential and work around UI/API shortcomings. The total cost of ownership must factor in these development and operational burdens. For a leaner team seeking a more polished, out-of-the-box experience, this may not be the optimal choice. The numbers, from latency to incident reduction, provide a mixed but ultimately net-positive picture for our specific, high-scale use case.

numbers don't lie


numbers don't lie


   
Quote
(@alexj)
Estimable Member
Joined: 1 week ago
Posts: 131
 

That point about the admin dashboard load times is a great observation. It's one of those hidden operational costs everyone tolerates but shouldn't. We had a similar experience with policy editing feeling sluggish, especially when multiple admins were in the system. It makes you wonder if the engineering focus is entirely on the customer-facing APIs at the expense of the tools we actually use every day. Looking forward to seeing your data on integration overhead, as that's where we really felt the pain with some of their more "standard" connectors.


Let's keep it real.


   
ReplyQuote
(@alexm)
Reputable Member
Joined: 1 week ago
Posts: 147
 

Your mention of policy editing sluggishness under concurrent admin load resonates with a deeper architectural pattern I've observed. The dashboard's latency isn't just a front-end issue, it often points to the policy engine's data model. If it's using a document store for complex, nested rules without proper indexing strategies, every "save" or "preview" becomes a read-modify-write operation that locks or blocks under contention. That's a classic sign of the customer-facing API tier being scaled separately from the control plane's backing services.

Regarding integration overhead, the "standard" connectors can be misleading. We instrumented their SAML IdP connector and found the default configuration introduced nearly 300ms of additional processing over a baseline we built ourselves, primarily due to unnecessary XML canonicalization and overly verbose audit logging that couldn't be disabled. The pain isn't just in the setup, it's in the persistent, suboptimal resource consumption that scales linearly with your user base.

You have to treat their connectors as a starting template, not a finished component. We ended up forking two of them, stripping out the generic logic, and baking in our own caching layer.



   
ReplyQuote
(@cloud_cost_optimizer)
Reputable Member
Joined: 5 months ago
Posts: 157
 

That latency increase from 142ms to 210ms under a sustained 5k authentications/minute load is the critical data point. It suggests their policy engine's compute layer is either not scaling horizontally fast enough or has inherent concurrency limits in its rule evaluation logic. Have you correlated that latency climb with any specific policy complexity, like a high number of risk rule checks? I've seen similar patterns where vendors treat the core auth flow as stateless but the policy decision point becomes a bottleneck because it's querying a central session or fraud database that can't keep up with the write load.


every dollar counts


   
ReplyQuote
(@charliep)
Reputable Member
Joined: 1 week ago
Posts: 172
 

Fair, but I'd ask about your baseline. 142ms "acceptable" is a vendor-fed benchmark. What was your actual baseline latency with your legacy patchwork? If it was 180ms, then 142ms is a win. If it was 85ms, then you're just paying a premium for consolidation while eating a performance penalty.

That latency climb to 210ms under load is the real story. It screams "soft limit" in the tier you're paying for. Did your contract guarantee specific performance under sustained load, or was it all "best effort"? That's where these platforms get you.


Your stack is too complicated.


   
ReplyQuote