User Access Security in AWS Organizations

The human factor is the largest source of security incidents in an AWS estate, and it fails in two ways more often than any other:

1. Access key leakage — a static key committed to a repository, pasted into a ticket, or left in a configuration file that later becomes public.
2. Credential compromise — phishing, social engineering, credential stuffing and brute force against a password that was reused elsewhere.

Both are addressed by the same change: stop issuing long-lived credentials to people.

IAM users versus IAM Identity Center

	IAM users	IAM Identity Center
Credentials	Static access keys and passwords. Rotation is possible but manual and disruptive	Roles issuing short-lived credentials, rotated automatically every session
Account reach	One user maps to one account	One user reaches many accounts
Permissions	Usually one permission set per user	Many permission sets, assigned per account
Federation	No native integration with an external directory	Built for it — Active Directory, Entra ID, Okta and any SAML 2.0 provider
Suitability	Small, single-account setups, and the few workloads that genuinely cannot federate	Any workforce access at organisation scale

IAM Identity Center (formerly AWS Single Sign-On) is the answer for people. IAM users should be the documented exception, each with an owner and a review date.

Active Directory integration

Where an organisation already runs Active Directory, IAM Identity Center can use it as the identity source rather than duplicating the directory.

AD Connector proxies authentication requests to an existing on-premises Active Directory:

• Existing users and groups grant permissions in AWS accounts
• Credentials stay in the corporate directory — nothing is synchronised or duplicated
• Group structure and joiner/leaver processes continue to work unchanged
• AWS permissions are managed through IAM Identity Center permission sets

AWS Managed Microsoft AD is the alternative when a directory is needed in AWS itself, for directory-aware workloads as well as for sign-in. See AWS Directory Service.

Where the identity provider is Entra ID or Okta rather than Active Directory directly, SCIM provisioning keeps users and groups in step automatically. Some identity providers — AD FS among them — have no compatible SCIM implementation, and in those cases users and groups are provisioned by hand or the directory is fronted by a provider that does support SCIM. See SCIM.

Multi-factor authentication

MFA is the single control that most reduces the impact of a stolen password.

• Enable and enforce it organisation-wide through IAM Identity Center, so it applies to everyone rather than to whoever opts in
• Prefer phishing-resistant factors — a FIDO2 security key or passkey — over time-based one-time passwords, which can be relayed by a convincing proxy
• Require it unconditionally for the management account root user, and store that credential where it takes two people to reach it

Monitoring what people do

Centralised, tamper-resistant logs. AWS Control Tower creates a log archive account automatically. Aggregate CloudTrail and AWS Config there, restrict who may read it, and give no workload account the ability to delete from it.

CloudTrail answers who did what: filter by role, user, time range and action. Enable an organisation trail so new accounts are covered from the moment they are created.

CloudWatch alarms on the events that matter — a root user sign-in, an MFA device being deregistered, CloudTrail being stopped, a mass deletion — rather than on volume.

GuardDuty covers what a rule cannot express: credentials used from an unusual location, API patterns that depart from the learned baseline, calls from addresses on threat intelligence feeds.

Practice

1. Use IAM Identity Center for role-based human access, and treat every remaining IAM user as an exception.
2. Let roles rotate credentials rather than rotating access keys by hand.
3. Integrate the existing corporate directory rather than duplicating it.
4. Enforce MFA organisation-wide, with phishing-resistant factors where possible.
5. Aggregate logging into an account the workload accounts cannot write to.
6. Alarm on loss-of-control events, and route the alarms somewhere a person reads.
7. Assume a credential will be compromised, and build the layers that limit what happens next.

Session hijacking and well-targeted phishing remain live risks even with all of the above in place. Regular access reviews, short session lifetimes and a rehearsed revocation procedure are what shorten the window between compromise and containment.