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.

The mistake that compounds for years

In most AWS migrations at Nigerian Tier 1 scale, the most expensive mistake is made before any workload exists — on the day the first AWS account is provisioned, before any architecture diagram has been signed off, when an engineer creates the first IAM user with administrative access "just to get the project moving." Eighteen months later that user is still active, still in three Slack DMs, still holding keys the engineer who created them does not remember issuing. The bank ends up with 47 AWS accounts, no consistent role taxonomy, no clear answer to "who has standing access to production," and a CBN examiner asking exactly that question.

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 that the perimeter of the new platform is identity, not network.

Why identity is the perimeter

A 2026 Tier 1 bank running on the architecture described 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 thing the SecPoint Protector firewall at the data centre defends, the thing the AWS Network Firewall defends on the cloud side — is necessary and not sufficient. 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, what CIS Controls v8 Control 5 and Control 6 codify operationally, and what the CBN CSAT directive of 30 March 2026 implies when it asks the bank to demonstrate "controls over privileged access to systems supporting critical operations." It is also what every counter-party assurance team — international card scheme, correspondent bank, EU partner — increasingly asks first.

The three principles

Three principles structure the IAM architecture we deploy:

1. 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.

2. 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, not held standing.

3. Identity is observable. Every identity action — every role assumption, every session, every privileged operation — produces an audit event that lands in CloudTrail Lake, the audit-evidence layer documented in the operational-implementation article. 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 identity provider as the 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 that require MFA on every authentication, with hardware token or platform authenticator preferred over TOTP, TOTP preferred over SMS. SMS as MFA is, in 2026, 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 capped at 15 minutes for production, 1 hour for non-production. Standing sessions are how stolen tokens become incidents.
• Permission Sets designed for job functions, not for 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 assigned to anyone standing. Administrative permission sets exist but are gated through a just-in-time elevation workflow (more on that below).
• SCIM provisioning automated. Users and groups in the IdP map to users and groups in Identity Center automatically. There is no manual provisioning step where a human creates a user in IAM Identity Center.

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 the policies on that session being the union of permission sets the user is authorised for.

Role design — the eight roles that cover 95% of the bank

The reference design we recommend uses eight role archetypes which 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 is different 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 is opened with a 30-minute timer, the session is recorded (via Systems Manager Session Manager logging), 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.

IncidentResponder is the role IR-team members assume when an incident is declared. It carries elevated access scoped to the incident's affected services. The role 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 are how the bank reconciles 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 / 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 in any workload

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 → 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 → 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 → 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) → OIDC trust. GitHub Actions and GitLab CI both support OIDC federation to AWS. 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 → 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 that were architected against environment-variable credentials have to be refactored, redeployed, and tested. The bank's engineering teams generally welcome this; legacy applications less so. The endpoint is the same: 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 described above 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; for AWS console sessions, the CloudTrail event stream provides the activity trail; for any access that bypasses both (very rare in a well-designed identity-first stack), the IAM action audit log provides the record.

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.
• 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.
• Quarterly review of standing privileged access — 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. The question "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 sequence we deliver, in eight to twelve weeks, before the AWS-for-banks architecture landing zone is built out:

• Weeks 1-2 — 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 — IdP hardening. MFA enforced for every user, conditional access policies, JIT deprovisioning workflows, hardware security keys procured for privileged users.
• Weeks 3-6 — IAM Identity Center setup. Federation from the IdP, permission set design, SCIM provisioning, role-mapping exercise with the bank's HR and platform-engineering teams.
• Weeks 5-8 — 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 — Workload identity migration. Existing applications that were running on static credentials (if the bank already has any AWS presence) migrate to IRSA, instance profiles, OIDC federation. New applications launch with workload identity from day zero.
• Weeks 8-10 — Break-glass and incident-responder workflows. Just-in-time elevation tooling deployed, two-party approval flow configured, session recording enabled, 24-hour review SLA operating.
• Weeks 9-11 — Audit-evidence integration. 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 — 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 this lands

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.

That is the bar. The work that gets a bank to it is technical, sequential, and unglamorous. It is also the work that converts "we moved to AWS" into "we moved to AWS and the bank is materially harder to compromise than it was twelve months ago." Anything less is theatre.

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.