Credential Risk

Understand persistent and interactive AWS identity credentials that deserve security attention.

IAM security is not only about permissions. An identity can have appropriately scoped permissions and still create risk through old access keys, unused credentials, privileged long-lived keys, missing MFA, insecure root-account posture or a weak account password policy.

Securitain separates these credential questions from authorization analysis so teams can investigate both dimensions.

Where to find Credential Risk

The current sub-navigation is:

• Access Keys
• Root Account
• MFA & Passwords

Individual IAM-user MFA status is also available in IAM Analyzer → Inventory → Users.

Access Keys

IAM access keys are long-lived credentials associated with IAM users. Modern AWS architectures should minimize unnecessary long-lived keys, particularly for human users, administrative identities, CI/CD workloads that can use federation, and cloud workloads that can use IAM roles.

The current summary cards include:

• Total Keys
• Active
• Over 90 Days
• Never Used
• Admin-owned

The current table can display:

• user and AWS account
• masked Key ID
• status, age, last used, last used service
• owner privilege, risk and recommendation

Key age

Older access keys can increase security risk when rotation and ownership are weak. The current product highlights keys older than 90 days as one review category. This is not a universal AWS law — organizations can define different credential standards. Age is evidence for review, not automatic condemnation.

Never-used keys

A key that has never been used may be unnecessary, abandoned or intentionally reserved.

Active vs inactive

An inactive key cannot be used for normal API authentication while inactive. But inactive keys still provide useful governance context — is the key retained unnecessarily? Is it part of a staged rotation? Is the associated IAM user still required? Use status together with age and ownership.

Admin-owned keys

A long-lived key associated with an administrative IAM user deserves higher scrutiny because compromise can have broader consequence.

Long-lived Access Key
      +
Admin-capable User
      ↓
High credential consequence

Use IAM Blast Radius for broader consequence analysis.

Last used

Where AWS provides usage context, Securitain can show last-used date and last-used service. This helps answer whether the credential appears operationally active. However, historical usage evidence should not be treated as proof that every possible use has been observed.

Root Account

The AWS account root user has unrestricted account-level authority by design. It should be treated differently from normal IAM identities.

Root MFA

Root MFA is a critical account protection. Securitain can show whether supported AWS root-account MFA posture is enabled or disabled. A root account without MFA deserves urgent review.

Root access keys

Long-lived root access keys are an especially dangerous condition.

Root MFA: Enabled
Root Access Keys: None

Where available, Securitain can provide last-used context for the root account. A recent root usage event should be investigated according to the organization's operational model.

MFA & Passwords

The current view focuses on account password-policy posture.

Password policy

The current Securitain password-policy view can show:

• minimum password length
• required symbols, numbers, uppercase and lowercase characters
• password expiration setting and maximum password age
• password reuse prevention
• risk context

This helps security teams understand the IAM account password policy used for IAM users with console passwords. This does not govern IAM Identity Center password policy, external identity-provider policy, OIDC workloads or AWS roles.

Individual user MFA

Individual IAM-user MFA status is not primarily presented in the current MFA & Passwords card. To inspect users, open IAM Analyzer → Inventory → Users. The Users inventory includes MFA state per IAM user.

Account password policy
→ Credentials → MFA & Passwords

Individual IAM user MFA
→ Inventory → Users

Root MFA
→ Credentials → Root Account

MFA depends on identity type

MFA is primarily relevant to interactive human authentication. A workload role usually does not authenticate using a human MFA device. Do not flag absence of MFA on a non-interactive role as though it were a human console user.

Credential risk vs least privilege

A user can require remediation in both dimensions — an old admin access key combined with unused administrative permissions requires both credential and authorization attention.

Credential risk vs federation

One reason to reduce IAM access keys is that modern workloads can often use temporary credentials. Examples include EC2 instance roles, ECS task roles, EKS workload identity patterns, GitHub OIDC, IAM Identity Center and STS-based role sessions. The appropriate migration depends on the workload. Do not recommend one federation model for every use case.

Investigating a risky access key

1. 1

   Identify the owner

   Which IAM user owns it?

2. 2

   Determine whether the user is human or workload-oriented

   Human long-lived keys deserve special scrutiny.

3. 3

   Review key age

   Understand rotation expectations.

4. 4

   Review last usage

   Determine whether the key appears operationally active.

5. 5

   Review privilege

   Is the owner admin-capable?

6. 6

   Review alternative identity model

   Could the workload use temporary credentials through federation or role sessions?

7. 7

   Rotate or remove carefully

   Do not delete a production key before confirming dependencies.

Investigating weak password posture

1. 1

   Review account password policy

   Identify weak policy controls.

2. 2

   Review IAM users with console access

   Determine who is actually affected by the policy.

3. 3

   Review MFA state

   Focus on interactive users via Inventory → Users.

4. 4

   Improve the policy

   Apply changes through the customer's normal IAM process.

5. 5

   Verify in a later scan

   Use Scan Status and finding verification where applicable.

Evidence and limitations

Credential analysis depends on:

• credential-report information and access-key metadata
• key-last-used information where AWS provides it
• root-account security status and password-policy information
• user inventory and scan freshness

Related guides