Identity-First Migration: Why IAM Has to Be Architected Before the AWS Account Is Provisioned

Series · Hardening before AWS · Part 3 of 3 ← Part 1: Securing the application · ← Part 2: Mobile banking app hardening · Identity-first migration

Companion to the AWS-for-banks architecture series and the DSI banking threat picture.

A platform engineer at a Tier 1 Nigerian bank logs into the AWS console for the very first time. The account is six minutes old. He creates an IAM user named admin, attaches AdministratorAccess, downloads the access keys, and pastes them into Slack so a colleague can help him spin up the first staging environment. The migration project plan calls this "day zero." Eighteen months later, that user is still active. The keys are still valid. Nobody remembers who has them.

This is how identity-debt begins at Nigerian banks. Not with a breach. Not with a clever attacker. With a single line of "just to get moving" that compounds for years, accumulating like compound interest on a debt nobody recorded in the books — until a CBN examiner asks who currently has standing administrative access to production, and the bank has to admit it does not know.

The Sequence That Has To Invert

The fix is to invert the sequence. Identity is the first migration step, not the last. The IAM perimeter is architected, deployed, and tested before the landing-zone Terraform from the AWS-for-banks architecture series is applied. The first workload account in the landing zone is created by federated identity, owned by a documented role, audited from day zero. There is never an IAM user with a long-lived access key issued to a human. There is never standing administrative access to production.

This piece documents the identity-first programme. It is the work that converts "the AWS migration" from an infrastructure project into a posture programme — by ensuring the perimeter of the new platform is identity, not network.

Why Identity Is The Perimeter

A 2026 Tier 1 bank running on the architecture in Part 2 of the AWS-for-banks series has its data centre in Lagos, an AWS landing zone in Frankfurt and Cape Town, a Direct Connect circuit between them, and no public-internet exposure for control-plane access. The network perimeter — the SecPoint Protector firewall at the data centre, the AWS Network Firewall on the cloud side — is necessary and not sufficient.

Picture a fortress with armoured walls and a locked gate. Now picture the front-desk clerk handing the key to anyone wearing the right uniform. The path that compromises a Tier 1 bank's AWS environment in 2026 is not a hole in the firewall. It is a credential. A leaked access key, a compromised SAML assertion, a session token stolen from a developer's laptop, an over-privileged role that an engineer escalated to two years ago and nobody removed.

The control that closes those paths is identity. Federated, short-lived, audited identity is the perimeter. Network controls are a backstop. This is what the NIST Risk Management Framework authorisation boundary is about. It is what CIS Controls v8, Controls 5 and 6, codify operationally. The CBN CSAT directive of 30 March 2026 means the same thing when it asks the bank to demonstrate controls over privileged access to systems supporting critical operations. And it is what every counter-party assurance team — international card scheme, correspondent bank, EU partner — increasingly asks first.

The Three Principles

The IAM architecture rests on three principles.

No long-lived static credentials. No human ever holds an IAM access key. No application ever holds an AWS access key in a config file or environment variable. Workload identities are short-lived, federated, attested. Human identities flow from the bank's identity provider through IAM Identity Center as short-lived federated sessions. The unit of access is a session, not a key — the way a hotel issues a card that expires at checkout rather than a master key.

Least privilege as a default, not an aspiration. Roles are designed for specific job functions, not for "the cloud team" or "developers." Each role's permissions are the smallest set that allows the function to work. Where a role needs administrative access, that access is time-bounded — granted via a just-in-time elevation workflow that expires automatically, never held standing.

Identity is observable. Every identity action — every role assumption, every session, every privileged operation — produces an audit event that lands in CloudTrail Lake. The CISO knows, in minutes, who is currently in production. The CBN examiner knows, in seconds, who has had administrative access in the past ninety days.

The Architecture

The shape of the identity-first IAM stack we deploy at a Nigerian Tier 1 bank:

┌─────────────────────────────────────────────────────────────────┐
│  Bank's identity provider (Azure AD / Entra ID, Okta, ADFS)    │
│  ─ source of truth for all human identities                     │
│  ─ MFA enforced at IdP level                                    │
│  ─ conditional access policies on device posture and location   │
└─────────────────────────────────────────────────────────────────┘
                          │ SAML 2.0 / OIDC
                          │ SCIM 2.0 for provisioning
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│  AWS IAM Identity Center  (the AWS-side identity broker)        │
│  ─ federates from the bank's IdP                                │
│  ─ assigns Permission Sets to AWS accounts                      │
│  ─ issues short-lived (15-min) session credentials              │
│  ─ no long-lived users; no static access keys                   │
└─────────────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
   ┌─────────┐       ┌─────────┐       ┌─────────┐
   │ AWS Org │       │ AWS Org │       │ AWS Org │
   │ Member  │       │ Member  │       │ Member  │
   │ Account │       │ Account │       │ Account │
   │  Prod   │       │  UAT    │       │ Sec/Log │
   └─────────┘       └─────────┘       └─────────┘
        │                 │                 │
        ▼                 ▼                 ▼
   Workload identities (IRSA, IAM Roles, AssumeRole-from-EKS)
   no static credentials in any workload
                          │
                          ▼
                  CloudTrail Lake
                  + Security Lake
                  + IAM Access Analyzer
                  ─ audit-evidence vault
                  ─ examiner-queryable

Every line in the diagram is deliberate. Five elements deserve specific treatment.

The Bank's IdP As Source Of Truth

The bank already operates an enterprise identity provider. Azure AD / Microsoft Entra ID is the most common in the Nigerian Tier 1 estate; Okta and ADFS feature in the others. Whatever the provider, it is the source of truth for human identity. Three things have to be in place before the IAM Identity Center federation is wired.

MFA enforced for every user. The IdP is the right place to enforce MFA — once, for every downstream service. Conditional-access policies require MFA on every authentication, with hardware token or platform authenticator preferred over TOTP, TOTP preferred over SMS. SMS as MFA in 2026 is a residual fallback for legacy users, not a default.

Conditional access on device posture. Authentication from an unmanaged device, from an unexpected geography, or from a device that fails endpoint-security posture (no recent EDR check-in, missing security baseline) triggers either additional friction or refusal. The IdP is the policy-decision point.

Just-in-time deprovisioning. When a user leaves the bank, the offboarding workflow deactivates them in the IdP, and SCIM provisioning propagates that deactivation to IAM Identity Center within minutes. There is no scenario where a former employee's federated AWS access continues to exist for days. The bank's IdP is where identity discipline lives. The cloud architecture borrows from it; it does not duplicate it.

IAM Identity Center As The AWS-Side Broker

IAM Identity Center (the rebranded AWS SSO) is the AWS-side identity broker. It federates from the bank's IdP via SAML 2.0 or OIDC and assigns Permission Sets — collections of IAM policies — to combinations of users and AWS accounts. A user authenticates to the bank's IdP. The IdP issues a SAML assertion. IAM Identity Center receives it, looks up the user's permission set for the target account, and mints a 15-minute session credential. The user uses the credential, it expires, the user re-authenticates.

The configuration matters. Session duration is capped at 15 minutes for production, 1 hour for non-production — standing sessions are how stolen tokens become incidents. Permission Sets are designed for job functions, not individuals or teams: "ApplicationDeveloper-Mobile-NonProd", "FraudAnalyst-ProdReadOnly", "PlatformEngineer-Prod-BreakGlass", "AuditOnly-AllAccounts". Each permission set has a documented purpose, owner, and renewal cadence. No "AdministratorAccess" permission set is assigned to anyone standing — administrative permission sets exist but are gated through a just-in-time elevation workflow. SCIM provisioning is automated, with users and groups mapping from IdP to Identity Center without a human creating accounts.

The output of this configuration is that every human's access to AWS, in every account, is a short-lived federated session traceable to a specific authenticated user, with policies that are the union of permission sets the user is authorised for.

Eight Roles That Cover 95% Of The Bank

The reference design uses eight role archetypes that cover the working access patterns of 95% of the staff who touch AWS at Nigerian Tier 1 scale. Each gets a permission set per environment, so a developer's NonProd permission set differs from their UAT permission set, which differs from their Prod-Read-Only set.

Two roles deserve special treatment.

BreakGlassAdmin is the role that gives administrative access to production. It is never standing. Access is granted through a just-in-time elevation workflow: the user requests elevation with a documented reason, two designated approvers (typically the CISO and the Head of Platform Engineering) approve, the session opens with a 30-minute timer, the session is recorded via Systems Manager Session Manager, and the session is reviewed within 24 hours by a third party who was not the approver. The workflow's audit log is the evidence chain. It is the bank's fire-axe-behind-glass: present in case it is needed, never wielded routinely, every use leaves a record.

IncidentResponder is the role IR-team members assume when an incident is declared. It carries elevated access scoped to the incident's affected services. It is assumed via the same JIT elevation workflow as break-glass but with a faster approval path — one approver, the Head of SOC or the CISO, during an active incident. The session is recorded; the audit log feeds the post-incident review.

These two roles reconcile the principle of "no standing administrative access" with the operational reality that sometimes someone has to be administrator for thirty minutes to fix a real problem.

MFA, Done Properly

Every authentication to the bank's IdP carries an MFA challenge. The hierarchy of factors, in order of preference.

Hardware security key — WebAuthn, FIDO2. YubiKey, Titan Security Key, Feitian. Phishing-resistant, cryptographically attested, the strongest available. We deploy these for every privileged user (BreakGlassAdmin, IncidentResponder, SecOpsAnalyst, Platform Engineer) without exception.

Platform authenticator — Touch ID, Windows Hello, Android Biometric Prompt with WebAuthn. Strong, phishing-resistant, lower friction than a hardware key. Default for general users on supported devices.

TOTP via an authenticator app. Google Authenticator, Microsoft Authenticator, Authy, 1Password. Adequate but susceptible to real-time phishing. Default for users on devices without platform authenticator support.

Push notification with number matching. Microsoft Authenticator push with the user typing a number shown in the IdP. Stronger than tap-to-approve push. Acceptable as a secondary factor.

SMS or voice OTP. Residual fallback only. Documented as such. Subject to phase-out for high-privilege users.

The CBN CSAT directive and the NDPA implementation expectations both treat MFA as a baseline control. Nigerian Tier 1 banks are at varying stages of moving off SMS as a default factor. The architecture we recommend makes hardware keys the default for privileged access and platform authenticators the default for general users.

Workload Identity — No Static Credentials, Anywhere

Human identity is one side. Workload identity is the other. Every application running on AWS — every container in EKS, every function in Lambda, every EC2 instance, every CodeBuild project — needs to talk to other AWS services. The naive way to do this is a static access key in an environment variable. We do not deploy this. The mechanisms we use instead, per workload type:

EKS pods use IRSA — IAM Roles for Service Accounts. The pod assumes an IAM role via the EKS OIDC provider. No static credentials in the pod, the deployment YAML, or the container image. Each microservice gets its own role with permissions scoped to its function.

EC2 instances use an IAM Instance Profile. The instance metadata service returns short-lived credentials for the role attached to the instance. Application code reads from IMDS (v2, mandatory) without holding any static keys.

Lambda functions use an IAM Execution Role. The Lambda service injects role credentials into the function's environment automatically. No static keys.

CI/CD — CodeBuild, GitHub Actions, GitLab CI — uses OIDC trust. The CI runner authenticates as itself, claims a role via OIDC, gets short-lived credentials. No long-lived AWS keys in CI secrets.

Cross-account access uses AssumeRole with external ID for third-party integrations, with the third party never holding bank-internal credentials.

The migration from static credentials to workload identity is sometimes the longest single workstream in the identity-first programme. Legacy applications architected against environment-variable credentials have to be refactored, redeployed, tested. The endpoint is the same across every engagement: an inventory of AWS access keys that fits on one page, where every key on the page has a documented owner and a quarterly rotation.

Privileged Session Monitoring

The break-glass and incident-responder paths produce sessions that have to be recorded, reviewed, and archived. AWS Systems Manager Session Manager provides the recording capability for shell sessions to EC2 instances. CloudTrail provides the activity trail for AWS console sessions. The IAM action audit log provides the record for any access that bypasses both — vanishingly rare in a well-designed identity-first stack.

What we deploy. Session Manager logging enabled on every instance, with logs streaming to a dedicated CloudWatch log group with KMS encryption. CloudTrail Lake querying the union of Session Manager logs, IAM events, and console activity, so that "show me everything user X did in account Y during the past 24 hours" returns a coherent answer in one query. A 24-hour review SLA on every break-glass session — a reviewer who was not the approver reads the session log within 24 hours of the session closing and signs off on it; anomalies escalate. A quarterly review of standing privileged access, where the AuditReadOnly role itself reviews who currently holds permission sets above a threshold, what they have used those permissions for, and whether the assignment is still justified.

This is the layer that makes the privileged-access surface defensible against a CBN examiner. "Who had administrative access to production in the past quarter" returns an answer that is complete, time-stamped, and reviewable.

The Migration Sequence — Identity Before Infrastructure

The eight-to-twelve-week sequence we deliver before the AWS-for-banks architecture landing zone is built out:

Weeks 1-2 are discovery. Audit the bank's current identity provider configuration, document existing AWS accounts (if any) and their access patterns, identify the privileged-access stakeholders. Weeks 2-4 are IdP hardening: MFA enforced for every user, conditional access policies, JIT deprovisioning workflows, hardware security keys procured for privileged users. Weeks 3-6 are IAM Identity Center setup: federation from the IdP, permission set design, SCIM provisioning, role-mapping with HR and platform-engineering teams.

Weeks 5-8 see the landing zone provisioned. AWS Organization, OUs, member accounts. Every account from day zero managed through Identity Center; no AWS IAM users created for humans. Weeks 6-9 are workload identity migration — existing applications running on static credentials migrate to IRSA, instance profiles, OIDC federation, while new applications launch with workload identity from day zero. Weeks 8-10 deploy break-glass and incident-responder workflows: just-in-time elevation tooling, two-party approval flow, session recording enabled, 24-hour review SLA operating.

Weeks 9-11 integrate audit evidence — CloudTrail Lake, Security Lake, IAM Access Analyzer, Session Manager logs all flowing into the audit-evidence vault that the Part 2 architecture's audit layer will own. Weeks 10-12 are tabletop and handover: tabletop exercises against the break-glass and incident-responder flows, documented runbooks, sign-off from CISO and Head of Platform Engineering.

At the end of this twelve-week window, the bank has the identity perimeter in place. The landing-zone infrastructure that lands on top of it inherits the perimeter rather than improvising one.

The CSAT And NDPA Mapping

What Identity-First Does Not Do

Three honest limits.

Identity-first cannot fix a bad application security baseline. A federated session calling an application with a SQL-injection vulnerability still exfiltrates data. Part 1 is necessary, not optional.

Identity-first cannot fix a compromised endpoint. A user with a federated session on a device with a keylogger has handed the keylogger their session token. EDR, device posture conditional access, and the mobile-side controls in Part 2 are necessary.

Identity-first cannot fix bad operational hygiene. A bank that issues 500 BreakGlassAdmin elevations per month, none of them reviewed, has the workflow without the discipline. Identity-first is a posture, not a tool deployment.

Where The Three Pieces Land

When the three pieces of this Hardening-before-AWS series ship together — secure SDLC, mobile-app hardening, identity-first architecture — the bank has closed the three surfaces that the AWS-for-banks architecture series cannot defend by itself: the code that runs on the platform, the device that talks to it, and the identity that authorises everything. The architecture in Part 2 and the operational programme in Part 3 of that series then have something defensible to defend.

The Nigerian Tier 1 bank that runs all six pieces in 2026 has an audit-grade posture across application, device, identity, network, workload, and audit-evidence layers. The CBN examiner's questions return evidence in minutes. The NDPA assessor's questions return evidence in minutes. The international counter-party assurance team's questions return evidence in minutes. The threat picture the DSI banking briefing documents stops being something the bank reads about and starts being something the bank's posture is calibrated to.

The work that gets a bank to that bar is technical, sequential, and unglamorous. The platform engineer at the start of this piece does not need a more thorough orientation. He needs a federated session waiting for him the moment he opens the console — so the question of "just to get moving" never has to be asked.

The Hardening-before-AWS series: Part 1 — Securing the Application · Part 2 — Mobile Banking App Hardening · Part 3 — Identity-First Migration.

The AWS-for-banks architecture series — the threat picture (DSI ↗), the architecture, the operational implementation — is the substrate this prequel series prepares the application, device, and identity surfaces for.