Clutch Security sign-up experience - what to expect as a new customer

Having just navigated the gauntlet that is the Clutch Security sales and provisioning process, I feel compelled to document the experience for posterity. The marketing site, as is typical, paints a picture of frictionless, modern privileged access management. The reality, as you might suspect, involves a series of curious rituals and assumptions that seem at odds with the product's stated purpose of streamlining secure access.

The initial sign-up is deceptively simple—a form requesting the usual corporate details. However, this triggers not a self-service portal or a sandbox, but an immediate, high-velocity outreach from a sales engineer. The demo is comprehensive, I'll grant them that, but it's a perfectly orchestrated journey through a pre-configured tenant. The moment you express genuine interest and ask for access to poke around your own instance, the real process begins. You are presented with a "provisioning questionnaire" that is less about technical specs and more about extracting a full architectural diagram of your cloud footprint, a complete list of your identity providers, and a signed letter from your firstborn. The justification is, of course, "security best practices," which is an amusing stance for a PAM vendor to take when the process itself feels like handing the keys to the kingdom over a PDF form.

After a week of back-and-forth, they finally provision a tenant. The welcome email contains credentials that, ironically, violate every principle of least privilege. The initial admin account has global permissions with no MFA enforced at the outset. The getting-started documentation then instructs you to, and I quote, "immediately configure SSO integration and create break-glass procedures." The cognitive dissonance is staggering. You're sold a product to manage just-in-time, audited, privileged access, and your own onboarding is a permanent, standing privilege with a password emailed over TLS 1.2.

The technical integration itself is where the real fun begins. Their Terraform provider is version 0.8.1, and the documentation for linking with an existing HashiCorp Vault installation is a single page that essentially says "use our API." Speaking of which, here's a sanitized snippet of the API call required just to bootstrap a connection to our AWS Organizations master payer account. Note the sheer number of assumed permissions just for discovery.

```json
{
"cloud_connector_config": {
"name": "aws-org-audit",
"cloud_type": "aws",
"authentication": {
"role_arn": "arn:aws:iam::123456789012:role/ClutchDiscoveryRole",
"external_id": "a1b2c3d4-e5f6-7890-fedc-ba9876543210"
},
"discovery_settings": {
"scan_all_regions": true,
"include_organization_accounts": true
}
}
}
```

This role, per their guide, requires `Organizations:ListAccounts`, `STS:AssumeRole` on every account, and `IAM:ListRoles`—a policy document that would give any FinOps or SecOps person a minor heart attack. The promise is that it's a read-only discovery role, but the trust boundary is now effectively the entire multi-account structure. The sales response to this concern was, "Well, you have to trust us at some level." A comforting sentiment from a privileged access manager.

So, what should you truly expect as a new customer? Expect a sales process masquerading as a security review. Expect to do the heavy lifting of configuring the very guardrails the product is supposed to provide, just to make the platform itself safe to use. Expect API and infrastructure-as-code support that feels like an afterthought compared to the shiny dashboard. The core functionality around session recording and just-in-time elevation seems solid once you're past the irony-laden setup, but the path to get there is paved with contradictions. I'm curious if others have had similar experiences, or if my cynicism is simply being weaponized by a particularly clunky onboarding playbook.

-- Cam