Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Healthcare (fertility / IVF) |
| Cloud Environment | AWS |
| Workloads | Docker containers on EC2 |
| Code & CI/CD | GitHub, GitHub Actions |
| IAM Profile | 10–15 users with direct AWS console access |
| Team | CISO-led, no dedicated identity or security engineering |
| Primary Interest | Understanding and right-sizing who can do what in AWS |
| Cloudanix Scope | CIEM (primary), Just-In-Time Access (secondary) |
The Situation: Fifteen People, One Console, No Answer to “Who Can Do What?”
Ten to fifteen people had direct access to the AWS console. For a small healthcare organisation, that number feels manageable, small enough that it does not trigger alarm the way hundreds of identities in a large enterprise would. And that is exactly the trap.
The CISO could name the fifteen people. What the CISO could not do was answer the harder questions: What can each of them actually do? Which of those permissions has anyone actually used in the last ninety days? If one of these fifteen accounts were phished tomorrow, what is the blast radius? For an organisation whose AWS environment holds patient data, “we know who has access” is not the same as “we know what that access means.”
The permissions had accreted the way they always do in a lean team. Someone needed to troubleshoot an EC2 issue once, so they were granted broad compute permissions that were never removed. A contractor from the development partner needed console access during a delivery phase and may still have it. Roles were copied from other roles because that was faster than scoping them from scratch. The result was a set of fifteen identities whose real, effective permissions nobody had ever mapped.
The Priority: Make Identity Legible First, Then Reduce It
The team’s goal was, first, to understand identity, and second, to reduce standing access safely. That ordering matters. You cannot right-size permissions you cannot see. So the engagement centred on CIEM (Cloud Infrastructure Entitlement Management) to make the fifteen identities legible, with Just-In-Time access as the follow-on step to remove standing privilege where it was not needed day to day.
We were deliberate about proportion. For a team this size, the bulk of the immediate value is in CIEM: seeing unused permissions, understanding effective access, and acting on right-sizing recommendations. JIT is the natural next move, but it is layered in gradually, starting with the workflows that make it genuinely easy to adopt rather than trying to convert every access pattern at once.
Where the Gaps Were
1. Effective Access Was Never Mapped
AWS IAM permissions are the product of users, groups, roles, policies, and resource policies interacting. What a given person can actually do, their effective access, is rarely obvious from reading any single policy. This is precisely the gap CIEM is designed to close. The team had no way to compute this, so the true capability of each of the fifteen identities was unknown.
2. Unused Permissions Were Accumulating Risk
Permissions that are granted but never used are pure downside: they widen the blast radius of a compromised account while delivering no operational value. With no tooling to identify unused permissions, the team had no way to safely trim them. Every dormant permission on those fifteen accounts was risk with no offsetting benefit.
3. Standing Access to Sensitive Actions
Some of the fifteen users held standing access to sensitive operations they needed only occasionally, or during specific incidents. Standing privilege means the permission is available 24/7, whether or not it is in use, which is exactly the window an attacker needs. The team wanted a way to grant sensitive access only when required and revoke it automatically after, the just-in-time model.
4. Partner and Contractor Access With No Clear Expiry
The development partner’s people had needed console access during delivery. In lean teams, that access frequently outlives its purpose because nobody owns the offboarding step. The team suspected there was residual third-party access but had no clean way to confirm and reason about it.
The Cloudanix Solution
CIEM: Making Fifteen Identities Legible
Cloudanix CIEM connects to the AWS environment agentlessly through a read-only role and computes what the team could not compute by hand:
- Effective access: For each of the fifteen identities, what they can actually do once users, groups, roles, and policies are resolved together, not what a single policy document appears to say.
- Unused permissions: Which granted permissions have gone unused, the dormant privilege that should be trimmed to shrink the blast radius of any single account.
- Right-sizing recommendations: Specific, actionable guidance to move each identity toward least privilege, so the team is not left to design least-privilege policies from a blank page.
For a CISO who could name the people but not their real capabilities, this is the view that closes the gap. Within the same agentless onboarding used for cloud posture, the fifteen identities go from opaque to mapped.
From Findings to Least Privilege, Safely
Right-sizing is only useful if it can be done without breaking someone’s legitimate work. Because CIEM distinguishes used from unused permissions, the team can trim with confidence: remove what has demonstrably never been exercised, and scope what remains to observed need. This is the practical path to least privilege for a team that does not have an identity engineer to design policies from scratch.
Just-In-Time Access: Removing Standing Privilege Where It Hurts Most
Once the identities were legible, the team could see which sensitive permissions did not need to be standing. Just-In-Time access addresses those directly. Instead of a user holding a sensitive permission permanently, the permission is granted on request, for a bounded window, and revoked automatically when the window closes, moving toward zero standing privilege for the operations that carry the most risk.
For a team this size, adoption ease is what determines whether JIT actually sticks. So the focus is on the workflows that are frictionless from day one:
- Slack-based requests and approvals: A user requests access in Slack; an approver sees who is asking, for what, and why, and approves in the same place they already work. No new console to learn.
- Time-boxed AWS console access: Sensitive console access granted for a defined window and auto-revoked, so the standing-privilege window that attackers rely on simply is not there.
- Complete audit trail: Every request, approval, and expiry is logged, which for a healthcare provider doubles as access evidence when it is needed.
Deliberately, JIT is not pitched as an all-at-once transformation for fifteen people. It is the roughly one-fifth of the effort that follows the CIEM groundwork, starting with the Slack workflow because that is the version a lean team will actually keep using.
Governing Partner and Contractor Access
The residual third-party access the team suspected becomes both visible and controllable. CIEM surfaces the external and contractor identities and what they can reach; JIT converts ongoing partner access into time-boxed, approved, auto-expiring grants rather than standing accounts that outlive the engagement.
Platform Impact
15 identities Mapped from opaque to effective-access clarity | Unused perms Identified and safe to trim | Slack-native JIT Requests and approvals where the team already works | Zero standing privilege For the sensitive actions that matter most
The Bigger Picture: Small Teams Have an Identity Problem Too
It is easy to assume identity governance is a large-enterprise concern, that fifteen users is too small to worry about. The opposite is closer to the truth. A large enterprise usually has an IAM function watching this surface. A fifteen-person healthcare team has a CISO wearing several hats and no identity engineer. The permissions still sprawl; there is just nobody assigned to notice.
The fix is not to hire an identity team. It is to make the existing identities legible with CIEM, trim what is demonstrably unused, and remove standing privilege from sensitive actions with JIT that is easy enough that a small team actually adopts it. Fifteen well-understood, right-sized identities are far safer than fifteen identities nobody has ever fully mapped.
The Outcome
The provider went from being able to name their fifteen console users to actually understanding what each of them could do. Unused permissions were identified and trimmed, shrinking the blast radius of every account. Sensitive, occasionally-needed access moved from standing privilege to Slack-based, time-boxed JIT grants that revoke themselves. And the partner access that had quietly outlived its purpose became visible and governable.
Key Results
✅ Effective Access Mapped: All 10–15 console identities resolved to what they can actually do.
✅ Unused Permissions Identified: Dormant privilege surfaced and safely trimmable.
✅ Right-Sizing Recommendations: Actionable path to least privilege without an identity engineer.
✅ Slack-Based JIT: Requests and approvals in the tool the team already uses.
✅ Standing Privilege Removed: Sensitive AWS console access made time-boxed and auto-revoking.
✅ Partner Access Governed: Third-party access made visible and expiring by default.
Can You Name Your Cloud Users but Not What They Can Actually Do?
Cloudanix CIEM connects agentlessly and shows you effective access, unused permissions, and right-sizing recommendations for every identity in your AWS environment. Layer in Slack-native Just-In-Time access to remove standing privilege from the operations that carry the most risk, without adding headcount.
Book a Free Assessment to see your identities through Cloudanix.
