Choose an account model#
| Model | Where the role lives | What you must approve |
|---|---|---|
| Standalone | In the assessed account | Its account-local provider, trust conditions, and audit policy. |
| Direct role in each account | A dedicated role and OIDC provider in every approved account | The exact account list and a reviewed deployment in each. |
| Central security account | The OIDC entry role in the central account; separate audit roles in approved members | Both sides of each trust relationship and an explicit list of member-role ARNs. |
Direct account-by-account enrollment#
- Record every approved 12-digit account ID and the regions to assess.
- Obtain the right customer-specific onboarding link for the selected design.
- Deploy and verify one account first; then enroll the remaining approved accounts.
- Record the role ARN and integration status for each account, not just a total.
- Confirm an initial evidence run in each account. A connected management account does not prove member coverage.
The base CloudFormation template does not create a StackSet or member-account roles automatically. Do not assume that enabling AWS Organizations discovery grants assessment access everywhere.
Central security-account enrollment#
The entry role needs an explicit permission to assume each approved member role. Each member must trust the exact approved central role. Use the manual guide’s central-account policy examples and replace all placeholders with reviewed values.
Avoid wildcard member-role resources. Review service control policies, permissions boundaries, role trust, and session restrictions. An allow in one policy is not proof that effective access exists.
Keep a coverage register#
Track account ID, owner, environment, regions, role ARN, onboarding method, permission profile, last successful collection, and offboarding owner. Label excluded accounts explicitly. Send this non-secret register through your approved collaboration channel; never include tokens or session credentials.