Topic starter
07/06/2026 8:54 pm
TL;DR: C1.ai describes Tide’s move from static role-based grants to a needs-based model that pairs birthright access for low-risk tools with just-in-time access for sensitive systems, supported by Terraform, Jira integration, and access profiles for more than 2,000 users. Least privilege is becoming an operational pattern, not a policy statement, because standing access has to shrink to match real work.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “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.
Key questions
A: Use business risk and task sensitivity, not organisational convenience.
Q: Why does least privilege often fail when it is managed manually?
A: Manual access handling usually creates slow approvals, inconsistent context, and standing permissions that survive long after the original need has passed.
Q: What are the signs that an access model is not really operationalised?
A: The warning signs are repeated manual escalations, inconsistent approval paths across applications, and difficulty rolling back access cleanly after a change.
Practitioner guidance
- Standardise access by risk tier Map low-risk applications to birthright access and reserve just-in-time approvals for sensitive systems that move money or hold sensitive data.
- Move IAM changes into version control Keep access profiles, approval logic, and onboarding patterns in Terraform or an equivalent code workflow so changes are peer reviewed and reversible.
- Unify request handling across SSO and non-SSO apps Route non-SSO applications through the same request model by using groups and ticket integration so the fulfilment path stays consistent.
Bottom line: Tide’s model shows that least privilege only works at scale when access is separated by risk, not when every application follows the same grant pattern.
What's in the full article
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- Direct quotes from Tide’s identity leadership on why the organisation moved from static grants to needs-based access
- Implementation detail on how Terraform patterns are used to standardise access profiles and JIT workflows
- Examples of how C1 and Jira are connected to produce consistent work items for the identity team
- Specific onboarding and migration patterns for applications moving from manual access handling into the new model
👉 Read C1.ai's blog on Tide's least-privilege access model and Terraform workflow →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 14 hours ago by NHI Mgmt Group
08/06/2026 8:38 am
Least privilege is becoming an operating model, not an access policy. Tide’s shift shows that the real control is no longer the written rule about who should have access. The control is the repeatable mechanism that issues, constrains, and removes access as work changes. For IAM teams, that means policy only matters when it is encoded into provisioning, review, and rollback processes.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should IAM teams use one workflow for SSO and non-SSO applications?
A: Yes, as far as possible. Different technical back ends can still feed the same request, approval, and fulfilment pattern, which reduces variance and makes the governance model easier to audit. The practical goal is one decisioning process, not one authentication protocol.
👉 Read our full editorial: Tide’s least-privilege shift shows where IAM is heading
This post was modified 14 hours ago by NHI Mgmt Group