Clutch Security vs Transmit Security - real-world performance comparison

Having recently concluded a significant IAM modernization project for a financial services client migrating off a legacy on-premise solution, we conducted a thorough evaluation of two primary contenders: Clutch Security and Transmit Security. The requirement was for a cloud-native, API-first platform to handle customer identity (CIAM) and workforce access (IAM) for approximately 5,000 internal users and 2M+ external customers, with a heavy emphasis on real-time risk-based authentication and privileged access workflows. While both vendors checked the requisite boxes on their datasheets, the operational and performance characteristics under load diverged significantly, which is the nuance often missing from vendor comparisons.

Our testing methodology involved a staged approach:
1. **Synthetic Load Testing:** Using Terraform to deploy identical environments in AWS (us-east-1) for each POC, we simulated load patterns with Locust, focusing on three key transactions: user authentication (OIDC flow), token refresh, and a risk engine query (contextual authorization).
2. **Real-World Integration:** Implementing a subset of our actual integration stack—a Kubernetes cluster with Istio, our backend services, and a legacy system proxy—to measure latency introduced by the IAM layer.
3. **Cold Start & Scaling Observations:** Monitoring the behavior of serverless components (where applicable) and the time to scale under rapid, spiky load increases.

### Key Performance Observations

**Authentication Latency (p95, Normal Load):**
* **Clutch Security:** 142ms. Consistent, with minimal variance. Their routing nodes, deployed across three AZs, showed efficient session affinity.
* **Transmit Security:** 89ms. Notably faster for standard auth flows under baseline conditions.

**Authentication Latency (p95, 10x Spike Load):**
* **Clutch Security:** 156ms. A marginal increase, demonstrating robust auto-scaling.
* **Transmit Security:** 312ms. Significant degradation observed. Investigation pointed to warmer functions in their serverless architecture struggling with concurrent execution limits, causing queueing.

**Risk/Contextual Policy Evaluation:**
This was where the architectures differed most distinctly. Our requirement involved passing ~15 context signals (device, location, IP reputation, etc.) per auth decision.

```hcl
# Example of a complex policy we tested in Clutch's DSL
rule "high_risk_transfer" {
when {
context.action == "money_transfer"
context.amount > 50000
context.user.risk_score > 0.7
not context.location.country in allowed_countries
}
then {
challenge = step_up("reauth_with_otp")
log_severity = "high"
}
}
```

* **Clutch Security:** Policy evaluation added a consistent 40-50ms. Their engine appears to compile policies to a deterministic runtime format.
* **Transmit Security:** Policy evaluation was faster in simple cases (~20ms) but exhibited non-linear slowdown with nested rules or multiple data source calls, jumping to 100+ms in our complex scenario.

### Operational & Cost Implications

The performance profile directly impacted our architecture decisions and cost projections:

* **Clutch's** consistent performance under spike led us to forecast lower compute resource needs for surrounding services (fewer pods waiting on IAM decisions), simplifying capacity planning.
* **Transmit's** faster baseline performance was attractive, but the spike behavior would have required us to implement client-side backoff/retry logic and over-provision our Kubernetes Horizontal Pod Autoscaler thresholds, increasing complexity and cost.
* **Database Load:** Transmit's schema for logging/auth events, under our simulated load, generated 30% more IOPS on the managed PostgreSQL instance compared to Clutch's more batched write pattern, a non-trivial cost factor at our scale.

### Verdict for Our Use Case

We selected Clutch Security. The decisive factors were predictable performance under all load conditions, which is critical for our customer-facing applications, and a policy engine whose cost did not explode with complexity. For organizations with more stable, non-spiky load patterns or simpler policy needs, Transmit Security's faster baseline times and developer experience could be compelling. However, for environments requiring resilience to rapid scale and complex, risk-based access decisions, our data strongly favored Clutch.

I'm interested if others have conducted similar load tests, particularly around the scaling behavior of the risk engine API endpoints, or if you've found ways to architect around the spike-load limitations we observed.