TL;DR: Tide describes moving from static role-based grants to needs-based access, using birthright profiles for low-risk tools and just-in-time access for sensitive systems, with Terraform and Jira integrations to standardise approvals and rollbacks, according to ConductorOne. The shift shows that least privilege now depends on operationalising access as code, not just writing policy.
NHIMG editorial — based on content published by ConductorOne: How Tide Uses C1 to Operationalize Least Privilege at Scale
By the numbers:
- Tide manages birthright access for more than 2,000 users using C1 access profiles driven by HR personas.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams implement just-in-time access without creating too much friction?
A: Start with the systems that carry the highest business or data risk, then make the request path consistent and predictable.
Q: Why do role-based access models often lead to over-privilege over time?
A: Role models age because jobs change faster than entitlement reviews, and exceptions accumulate faster than teams clean them up.
Q: What do teams get wrong about managing access with configuration as code?
A: They often treat code as a faster way to do the same manual process.
Practitioner guidance
- Map access by risk tier, not by convenience Define which applications qualify for birthright access and which must always require just-in-time approval.
- Move access policy into version-controlled code Store entitlement profiles, approval rules, and application onboarding patterns in Terraform or an equivalent code repository.
- Tighten persona data before expanding profiles Validate that HR persona mappings, application ownership, and group memberships still reflect real job functions.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- The exact access-profile structure Tide uses for persona-driven birthright entitlements.
- The Terraform and YAML workflow details that show how identity changes are peer-reviewed and rolled back.
- The approval flow for sensitive systems, including how manager and application-owner decisions are wired together.
- The Jira integration pattern used to convert approved JIT requests into consistent identity-team work items.
👉 Read ConductorOne’s post on Tide’s least-privilege operating model →
Least privilege at scale: what Tide’s IAM model change means?
Explore further