#IAM #Zero Trust #Cloud Security #DevSecOps #AWS

Cloud Security & Protection · IAM

From 12 disconnected IAM configs to one Zero Trust access model — 200-engineer SaaS platform

100% MFA coverage · access provisioning from 2 days to 15 minutes

A 200-engineer SaaS platform had 12 AWS accounts with no SSO, no MFA enforcement, and no centralised offboarding. A routine audit found 34 ex-employees with active credentials — 3 with admin-level access. Adimen replaced the entire access model with a Zero Trust identity layer in a single, phased engagement.

Challenge

Four years of growth had produced 12 AWS accounts, each with its own IAM configuration and no central control. No SSO meant each account was managed independently. No MFA enforcement meant credentials alone were sufficient for access — including to production. No automated offboarding meant ex-employee access persisted indefinitely.

Approach

Okta deployed as the central identity provider, federated into AWS IAM Identity Center across all 12 accounts. Least-privilege permission sets designed per role. SCIM provisioning and offboarding automated. JIT elevation for privileged access. CloudTrail, Config, and Okta logs unified into a single audit trail.

Outcome

100% MFA coverage across all 12 accounts. Access provisioning reduced from 2 days to 15 minutes. All 34 stale credentials revoked on day one. Offboarding now executes in under 60 seconds. One audit trail across every account instead of 12 separate CloudTrail configurations.

100%
MFA coverage across all 12 AWS accounts — enforced at the identity provider level, not per-account
15 min
Access provisioning time — down from 2 days of manual IAM work per new engineer
34
Stale credentials found and revoked — including 3 ex-employees with admin-level access
<60 s
Offboarding time — SCIM deprovisions access across all 12 accounts in under a minute

Four years of growth. Twelve accounts. Zero central control.

The company had grown from a 10-person startup to a 200-engineer SaaS platform over four years. The AWS account structure had evolved organically — each new product workstream got its own account, each team managed their own IAM, and there was no overarching identity governance. By the time a security audit was commissioned, the access landscape was fragmented across 12 accounts, each with its own IAM users, permission policies, and access review processes (where they existed at all).

The audit finding that forced the issue: 34 IAM users belonging to former employees still had active credentials. Three of them had AdministratorAccess. None of the accounts had MFA enforcement configured — the policy said MFA was required, but nothing actually enforced it. Provisioning a new engineer took up to two days because it required a manual IAM configuration step in each account they needed access to. The security team recognised the problem, but fixing it required a decision on architecture, not just a cleanup script.

Three problems to solve simultaneously.

01 — Identity
No single source of truth

12 AWS accounts each managed IAM users independently. There was no HR system integration, no authoritative list of who should have access to what, and no mechanism for a security team to get a complete picture of all active credentials across the estate. Access review was manual, infrequent, and incomplete.

02 — MFA
No enforcement

MFA was documented as a requirement but not enforced. IAM policies did not condition access on MFA authentication state, and no IAM Identity Center was in place to provide a consistent enforcement point. An attacker with a compromised credential had unobstructed access to whatever IAM permissions the credential held.

03 — Provisioning
Slow in, never fully out

Onboarding required a manual IAM configuration in each of the relevant accounts — a 2-day process for engineers needing access to multiple accounts. Offboarding had no automated component: access was removed only when someone remembered to do it, which is how 34 ex-employee credentials survived.

One identity layer. Zero standing access.

Okta as central IdP

Okta deployed as the single identity provider, integrated with the company's HR system via SCIM. Every engineer's access lifecycle is now driven by HR state: a new hire triggers provisioning, a termination triggers deprovision. Okta enforces MFA at the authentication layer — regardless of which AWS account the engineer is accessing, MFA is required at the Okta level before any AWS session token is issued. Access policy is managed in one place, not 12.

AWS IAM Identity Center (SSO)

AWS IAM Identity Center federated with Okta as the SAML 2.0 IdP. Engineers authenticate once via Okta and receive role-based access to whichever accounts and permission sets their role entitles them to — no per-account IAM users, no long-lived access keys. The Identity Center console gives the security team a single view of all active sessions and permission set assignments across all 12 accounts.

Least-privilege permission sets

Permission sets redesigned from scratch for each role type: Developer, Data Engineer, DevOps, and Read-only. Each set was built to the minimum permissions required for the role's actual work — not the historical "give them AdministratorAccess and we'll restrict later" pattern. Privileged access (production deployments, security-sensitive operations) is available only via JIT elevation with a time-limited session and an approval gate.

Automated provisioning & offboarding

SCIM provisioning from Okta to IAM Identity Center means access changes propagate within minutes of an HR system change. A termination event in the HR system triggers Okta deprovisioning, which cascades via SCIM to Identity Center, which revokes all active sessions and removes permission set assignments across all 12 accounts — in under 60 seconds. The 34 stale credentials discovered in the audit were revoked on day one of the engagement.

From 12 disconnected accounts to one governed access layer.

Engineers Developer Data Engineer DevOps Read-only Identity Provider Okta MFA enforced Group-based access SCIM sync SCIM SSO portal AWS SSO IAM Identity Center SSO portal Permission sets AWS Organizations AWS Accounts (×12) Prod Clusters prod-us · prod-eu · prod-ap role-based access only Staging / Dev staging · dev · sandbox scoped permission sets Platform / Data platform · data · security + 3 acquired accounts Just-in-Time Elevated access request + approve + expire Offboarding Auto-revoke <60 seconds Single Audit Trail AWS CloudTrail · AWS Config · Okta event log every access event across all 12 accounts — visible from one place

One identity layer. Every door locked.

100%
MFA coverage. Enforced at the Okta layer — no AWS session is issued without a valid MFA authentication, regardless of account.
15 min
Access provisioning. An HR system update triggers SCIM, which propagates to IAM Identity Center and grants the correct permission sets across all relevant accounts.
34
Stale credentials revoked on day one — including 3 ex-employee admin accounts that had persisted undetected.
<60 s
Offboarding time. A termination event in HR cascades via SCIM to complete deprovision across all 12 accounts in under a minute.

Tech stack

Okta AWS IAM Identity Center AWS Organizations SCIM Terraform AWS CloudTrail AWS Config GitHub Actions

IAM sprawl across multiple accounts and no central control?
Let's fix it — before the next audit finds it for you.

Get in touch →
← Back to Case studies