Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Workforce and services marketplace platform |
| Company Size | Roughly 300 employees; small DevOps and tech-support teams |
| Cloud Environment | Four independent AWS accounts; production and non-production onboarded |
| Not Onboarded | Two experimentation accounts, kept light on tooling by design |
| Privileged Access | Three DevOps engineers hold production database access |
| Support Access | Read-only through a BI tool; data changes go through DevOps |
| Tooling Philosophy | Invest in controls once a workflow matures and the spend is justified |
| Focus Area | JIT scoped by risk, not by headcount |
The Situation: Small Number of People, Large Amount of Access
When people picture JIT access, they picture an engineering organization of hundreds, each needing temporary privileges across dozens of accounts. This customer looks nothing like that, and yet the case for JIT is just as strong.
The company has about 300 employees, but production access is concentrated in three DevOps engineers. Support teams do not connect to databases directly; they use a read-only BI tool, and anything that needs changing goes through a pull request that those same three people apply. The organization is deliberately lean about tooling. Their view is that every additional security product adds operational weight and access complexity, so they add controls where the risk is demonstrable and stop there.
They also run an account structure that reflects this thinking. There are four AWS accounts, kept isolated by design so that a failure in one does not spread. Production and non-production are fully managed. Two others, used for experiments and product exploration, run at very low cost with full admin access and little tooling. The team’s reasoning was that these accounts hold nothing worth the cost of heavyweight controls.
So the question was practical, not philosophical: for a company this shape, where does JIT actually pay off, and where is it wasted effort?
The Core Tension
A one-size-fits-all rollout would have been the wrong answer in both directions. Applying JIT to every account and every employee would add approval friction and cost where there is little to protect. Skipping it because “only three people have access” ignores what those three people can do. Each of them can reach production databases holding personal and payment-related records, and each is a single compromised laptop or phished session away from exposing all of it.
Headcount is a poor proxy for risk. What matters is what an identity can reach and how long it can reach it for. Three standing credentials into production carry more risk than three hundred read-only accounts into a sandbox.
Where the Gaps Were
Standing Access Concentrated in Very Few Hands
When access is held by three people, informal trust tends to substitute for process. Nobody requests access; they simply have it. There’s no approval, no stated reason, and no expiry, so there is also no record that distinguishes a routine session from an unusual one.
No Way to Prove Access Was Appropriate
Auditing frameworks such as ISO 27001 and SOC 2 ask who had access to production and why. “Three trusted engineers” is an answer an assessor will accept only if it is backed by evidence of how access was controlled and reviewed.
Wanting Controls That Match the Real Risk Surface
The team did not want enterprise-grade access governance on accounts that hold experiments. They also did not want sandbox accounts to become a back door. The right design had to treat the two tiers differently on purpose.
Budget Discipline
Every control had to earn its keep. A model priced or operated as though the company had hundreds of privileged users would not have cleared that bar.
How Cloudanix Addresses This Situation
Tier the Accounts by What They Hold
The most useful move was a simple classification, agreed up front.
| Tier | Accounts | JIT treatment |
|---|---|---|
| Tier 1: Production | Production AWS account and its databases | Full JIT: request, approval, time-box, auto-revoke, audit |
| Tier 2: Non-production | Staging and development | Lighter policy: shorter approval path, auto-approve for read-only |
| Tier 3: Sandbox | Experimentation accounts | Out of JIT scope by decision; covered by lightweight guardrails where needed |
Cloudanix only governs the accounts you onboard. Leaving the sandbox accounts out is a configuration choice, not a gap, and it keeps cost and friction proportionate.
Right-Size the Approval Path
For a three-person group, the approval design should be simple. One engineer requests access to a production database for a stated reason and duration. A peer approves it. The default is a short window, such as one hour, with the ability to extend through a new request. Read-only access to non-production can be auto-approved. As the team grows, approvals can move to multi-level quorum without changing how engineers request access.
Start With the Surfaces That Carry the Most Risk
The team’s highest-value starting points are production cloud-console access and production databases. Database JIT replaces shared database passwords with short-lived, identity-stamped credentials. Cloud JIT removes standing permission-set assignments on production accounts. Other surfaces, such as Kubernetes, VMs, or SaaS, can follow when the team decides they merit it.
Make the Audit Trail the Byproduct
Every request, approval, session, and revocation is recorded against a named identity in storage the customer controls. When an assessor asks who had production access last quarter and why, the answer is a filtered view, not a reconstruction. For a company this size, that turns a stressful audit task into a routine one.
Use Posture Signals to Decide Where to Look Next
Because Cloudanix also provides posture and identity visibility on the onboarded accounts, over-privileged identities show up in the same console. If a sandbox account ever starts to host something sensitive, the signal to bring it under JIT is visible rather than assumed.
A Sensible Rollout for a Lean Team
- Classify accounts. Write down which hold production data and which don’t. Share the classification with the team so the scope is a decision, not an oversight.
- Onboard Tier 1 and Tier 2 accounts. Connect the production and non-production accounts first.
- Set a default duration and approver per tier. One hour with a peer approver for production is a reasonable start.
- Run for a month. Watch how often access is requested, how long sessions really last, and which requests are repetitive.
- Tune. Auto-approve the predictable low-risk requests and keep human approval on the rest.
- Review the tier boundary quarterly. If a sandbox account gains sensitive data or external exposure, promote it.
What This Does Not Try to Do
- It does not govern accounts you haven’t onboarded. If an experimentation account has full admin and holds nothing sensitive, that is a risk you have knowingly accepted. If that changes, the account should move up a tier.
- It does not make a three-person approval model resilient to everyone being unavailable. Consider a documented emergency path, such as an incident-driven auto-approval policy, and a delegate for when the usual approver is away.
- It does not replace broader hygiene. Complement it with a periodic review of IAM users, keys, and unused permissions.
Platform Impact
| Dimension | Before | After |
|---|---|---|
| Production access | Standing for three engineers | Requested, approved, time-boxed |
| Evidence for auditors | “Three trusted engineers” | Named request, approver, duration, and activity |
| Sandbox accounts | Out of scope, undefined | Out of scope by documented decision |
| Friction for routine work | N/A | Low; non-production read-only auto-approved |
| Spend | N/A | Matched to the accounts and users that carry risk |
Key Outcomes
- ✅ Risk-Based Scope: Governance follows what an account holds, not how many people use it.
- ✅ No Standing Production Access: Even for a very small trusted group.
- ✅ Proportionate Friction: Approvals scale with sensitivity.
- ✅ Audit-Ready by Default: Every grant tied to a person, approver, reason, and window.
- ✅ Room to Grow: Add surfaces, approvers, and accounts later without redesign.
Is JIT Overkill for Your Team Size?
If only a handful of people hold privileged access, JIT is not overkill; it is concentrated risk made temporary. Cloudanix lets you start with the accounts and surfaces that matter and expand when your workflows do.
Book a Free Assessment to scope JIT to your own account tiers in under 30 minutes.
