Multi-Account Environments

Understand security risk across multiple AWS accounts without losing account context.

AWS enterprises commonly separate workloads into multiple accounts for production, development, shared services, security, data and sandbox environments. This separation can improve governance. But it can also make security relationships harder to understand because identities exist in different accounts, roles trust other accounts, resources grant cross-account access, central identity systems assign access across accounts and security controls vary by environment.

Securitain keeps account identity attached to security data while providing an All Accounts view across the connected estate.

Securitain organization vs AWS Organization

Securitain Organization
≠
AWS Organization

Connect accounts individually

Each AWS account is connected through its own customer-controlled connection context. The standard model uses a customer AWS account, cross-account IAM role, External ID where configured by the Securitain connection, and temporary STS credentials. Connecting multiple accounts does not require sharing one permanent access key.

Where to manage AWS accounts

Use Connect AWS for detailed onboarding instructions and AWS Accounts Administration for the full account lifecycle.

Account aliases

Securitain can associate a display name or alias with an AWS account. Raw twelve-digit AWS account IDs are difficult to reason about during investigations. Readable names such as Production, Shared Services and Security preserve account identity while making the data human-legible. Reports and views should preserve the underlying AWS account identifier where necessary.

The global account selector

The product header provides a current account scope. Options include All Accounts or an individual active AWS account. Changing the selected account changes the security scope for supported views.

What “All Accounts” means

All Accounts means the currently connected AWS accounts included in the authenticated Securitain organization's current-posture scope. It does not mean:

• every AWS account in an AWS Organization
• every AWS account owned by the customer
• every account ever connected historically
• disconnected accounts

Current posture

Disconnected accounts

When an account is disconnected:

• it is removed from the normal account selector
• new scans stop
• it no longer contributes to current posture
• historical information can remain for applicable history and governance
• the AWS-side role and CloudFormation stack may still need to be removed separately

See AWS Accounts Administration for the full disconnect and removal workflow.

Selected account vs All Accounts

All Accounts
Critical findings: 12

Production only
Critical findings: 7

Development only
Critical findings: 3

Security only
Critical findings: 2

Account-scoped IAM analysis

Supported IAM views use the global selected account. Examples include:

• IAM Overview and Inventory
• Findings, Credentials and Effective Permissions
• Cross-Account, Federation and Trust Policies
• Privilege Escalation and Least Privilege
• Reports

Some governance data such as Identity Center and Organizations can have organization-wide semantics and should clearly explain how account scoping applies.

Account-scoped Data Security

Data Security APIs also support account scope. When a specific account is selected, resource posture can be limited to that account. When All Accounts is selected, the view can aggregate across currently connected accounts where supported. This applies to S3, KMS, RDS, DynamoDB and Sensitive Access.

Scan All Accounts

Securitain can initiate an IAM assessment across all currently eligible connected accounts.

Scan All Accounts
      ↓
Batch
      ├── Production scan
      ├── Development scan
      ├── Shared Services scan
      └── Security scan

Batch identity

One multi-account scan trigger is represented as a batch containing account-level scan runs. The product can therefore report:

• total accounts and completed accounts
• failed accounts and partial state
• overall timing and total detected findings

Pre-scan connection validation

Before a multi-account IAM scan proceeds, Securitain can identify accounts whose current AWS role connection cannot be used. A failed account does not necessarily block every other connected account.

4 selected accounts
    ↓
3 can be assessed
1 connection blocked
    ↓
3 scans proceed
1 requires attention

Multi-account partial completion

Production       Completed
Development      Completed
Shared Services  Completed
Security          Failed

Cross-account relationships

Multi-account visibility becomes especially valuable for trust:

Development Account
     ↓ AssumeRole
Shared Services Account
     ↓ AssumeRole
Production Account

Use Cross-Account Access, IAM Relationship Graph, Privilege Escalation and Blast Radius for cross-account path analysis.

Shared-services architectures

Legitimate cross-account relationships commonly include central logging, central security, deployment tooling, networking, backup and shared data services. Securitain should not describe cross-account architecture as inherently dangerous. It should make the relationship explicit so the customer can distinguish expected, overly broad, unknown and high-consequence relationships.

Identity Center across accounts

Identity Center permission sets can be assigned into multiple target accounts:

PlatformAdmins
      ↓
Admin Permission Set
      ├── Production
      ├── Security
      └── Shared Services

AWS Organizations across accounts

If AWS Organizations data is available, the organization hierarchy and SCP guardrails can provide additional enterprise context. However, AWS Organizations is not required simply to connect multiple AWS accounts to Securitain.

Reports across accounts

Reports can use All Accounts or a selected AWS account where supported. Every report should preserve enough account context that findings cannot be mistaken as originating from another environment. For high-level reports, clearly identify report scope, included accounts and data freshness.

Findings across accounts

A finding should preserve AWS account, affected entity and account-specific evidence. This allows teams to distinguish an admin role in Development from an admin role in Production even when the finding category is the same.

Multi-account operating model

1. 1

   Connect accounts

   Add all relevant AWS accounts through the AWS Setup wizard.

2. 2

   Name/alias environments

   Add readable aliases to each account.

3. 3

   Run All Accounts assessment

   Assess the full connected estate.

4. 4

   Review Scan Status

   Understand which accounts and capabilities were covered.

5. 5

   Use All Accounts for enterprise prioritization

   Identify the highest-risk findings across the estate.

6. 6

   Switch to one account for investigation

   Scope findings and posture to the specific environment.

7. 7

   Follow cross-account relationships when needed

   Use Cross-Account Access, Trust Policies and the Relationship Graph.

Example investigation

Suppose the All Accounts view identifies a high-risk external trust finding originating from the Development account to a Production role.

• Switch to Production — review target role permissions using Effective Permissions
• Review cross-account trust — confirm which Development principal can assume the role
• Review Blast Radius — understand Production consequence
• Review business ownership — determine whether the relationship is intentional
• Remediate or govern — narrow/remove the trust or document accepted risk

The account selector supports moving from estate-wide discovery to account-level investigation and back.

Evidence and limitations

Multi-account analysis depends on:

• connected accounts and their connection status
• scan coverage and role permissions
• selected account scope and feature support

Related guides