Skip to main content

Member Enrollment

The Enrollment page shows all accounts enrolled in GuardDuty and their current enrollment phase. Use it to add new member accounts, retry accounts that failed during enrollment, and remove accounts from GuardDuty.

Accessing Enrollment​

In the Security Hub sidebar, open the GuardDuty group and click Enrollment.

If GuardDuty has not been set up yet, the page shows an information banner — GuardDuty is not set up yet for this customer. Complete the setup wizard first to enroll member accounts. — with a Go to setup button that opens the setup wizard.

Deployment Card​

At the top of the page, the Deployment card ("Where GuardDuty is administered for this organization") shows the current GuardDuty configuration:

  • Admin account: the administrator account ID
  • Home region: the GuardDuty home region
  • Linking regions: all regions where GuardDuty detectors are deployed

Progress Bar​

A progress bar appears below the Deployment card whenever the configuration is in the in_progress state or at least one member account is in an active enrollment phase. It shows the current job label (or "Working…" when the job has not set one) and percentage, and advances as the page polls the server.

If loading the configuration or the member list fails, an error panel with a Retry action appears above the Deployment card instead of the tables being silently empty.

Enrolled Accounts​

The Enrolled accounts card lists every account GuardDuty is currently managing; its subtitle counts them ("N accounts protected by GuardDuty"). The table has three columns — Account, Status and Actions, with the Account column reading Account name (account ID). When nothing is enrolled it reads No accounts enrolled yet — pick accounts below and add them to GuardDuty.

Phase Reference​

The Status column renders the phase as a coloured chip, title-cased.

PhaseChipColourDescription
pendingPendingGreyEnrollment submitted, waiting to start
enablingEnablingBlueGuardDuty detector is being created in the account
invitingInvitingBlueInvitation sent to the member account
acceptingAcceptingBlueAccepting the member association on behalf of the account
enabledEnabledGreenFully enrolled and active
failedFailedRedAn enrollment failed; see the error message below the chip
remove_failedRemove FailedRedA removal failed. GuardDuty is still running (and still billing) in that account
removingRemovingAmberRemoval is in progress

failed and remove_failed are deliberately separate, because they need opposite jobs: a broken enrollment needs the enrollment re-run, a broken removal needs the teardown resumed. Running the wrong one would re-enable GuardDuty in the account you were trying to remove, so the two never share a chip or a button.

When a member account spans multiple linked regions, the Status chip shows the worst phase across all regions, in this order: failed, then remove_failed, then pending, then any active phase (enabling, inviting, accepting, removing), and only then enabled. A spinner appears next to the chip while any region is in an active phase.

Error messages (when present) appear beneath the status chip as region: error text, joined with a bullet when more than one region failed.

The admin account is always listed, is labelled with an admin chip, and offers neither Retry nor Remove.

note

An account whose removal completed is not listed here. Its rows are kept in the database with the phase disabled, but the page treats them as not enrolled, so the account moves down to the Not enrolled table and can be added again.

Retrying a Failed Account​

A Retry button appears only on a non-admin row whose worst phase is failed.

  1. Click Retry next to the failed account.
  2. Prism reuses the root email already stored for that account, resets its rows to pending, increments its retry counter, and re-runs enrollment. The page reloads and the account moves back through the enrollment phases.
  3. If the retry fails again, check the error message and verify the root email is correct. See Security Hub Issues for common causes.

Retry is refused when the account has no stored contact email, when the row is no longer in the failed state, or when the overall configuration is mid-operation (only enabled and partial_failure configurations accept a retry).

note

Retry never appears on a failed single-account removal. A row whose worst phase is Remove Failed gets no Retry button at all — its removal button is relabelled Retry removal instead, and pressing it resumes the teardown. If a retry is sent for such an account through the API, it is routed to the teardown rather than to enrollment, and one region's failed removal is enough to route the whole account that way.

caution

Two other teardowns do not produce the Remove Failed phase, and their rows are indistinguishable here from a failed enrollment:

Both leave the affected rows showing plain Failed, so this page offers Retry on them — and Retry means enroll. If you are tearing GuardDuty down, re-run the disable or the region change instead of pressing Retry here.

Adding Member Accounts​

The Not enrolled card ("Linked accounts that GuardDuty is not watching yet") lists all accounts in your organization that GuardDuty is not currently managing. When there are none it reads All linked accounts are already enrolled.

  1. Select the accounts you want to enroll. Use the header checkbox to select or clear every listed account at once, or check individual rows.
  2. Click Add N to GuardDuty in the card header (where N is the number of selected accounts; the button is disabled until you select at least one).
  3. Prism attempts to resolve the root email address for each selected account automatically.
    • If all root emails resolve successfully, the accounts are added immediately and appear in the Enrolled accounts table.
    • If any root emails cannot be resolved, the Enter root emails dialog opens.

Enter Root Emails Dialog​

The Enter root emails dialog appears when one or more selected accounts could not have their root email address resolved automatically:

We could not auto-fetch the AWS root email for the accounts below. Enter each account's root email to enroll it in GuardDuty.

For each listed account:

  • The account name and ID are shown on the left.
  • An editable Root email field is shown on the right. Its helper text is the reason the lookup failed, or Auto-fetch failed — enter this account's AWS root email when no reason was returned.
  • Enter the account's real AWS root email address.

To find a member account's root email, sign in to that AWS account and go to Account Settings > Account > Email address in the AWS Console.

Add to GuardDuty stays disabled until every listed account has an address. Cancel closes the dialog and discards what you typed; the account selection is left intact.

warning

Each member account must use its real AWS root email address. An incorrect or placeholder email causes an EmailVerificationFailed error and the account cannot be enrolled. Do not use IAM user emails, distribution lists, or aliases. Prism additionally rejects any address shorter than 6 or longer than 64 characters.

info

You do not have to split a large selection yourself. Prism sends the lookup in batches of five accounts, one batch at a time, and the server resolves the accounts within a batch in parallel — small enough that no single request runs into the gateway timeout. A large selection still takes proportionally longer before the dialog (or the enrollment) appears.

Adding members is only accepted while the configuration status is enabled or partial_failure. If another GuardDuty operation is still running, the request is refused with cannot add members while config status is ….

Removing a Member Account​

  1. In the Enrolled accounts table, click Remove next to the account you want to remove. The button is present on every non-admin row except one already in the removing phase. On a row whose worst phase is Remove Failed the same button reads Retry removal, because pressing it resumes a teardown rather than starting one.
  2. The Remove account from GuardDuty dialog asks Remove <account ID>? GuardDuty in that account will be disabled. Click Remove to confirm, or Cancel to back out. There is nothing to type to confirm.
  3. The account enters the removing phase. Prism disassociates and deletes the member from the administrator's detector in every linked region, then deletes the account's own detector in each region.
  4. When removal completes, the account disappears from the Enrolled accounts table and reappears in the Not enrolled table so it can be re-enrolled later. Its cached findings are deleted from Prism at the same time, so they stop counting towards the Threat Dashboard and stop appearing in the findings list.
warning

Removing an account disables GuardDuty in that account across all linked regions. The admin account cannot be removed — disable GuardDuty from Settings > Danger zone instead.

note

If any part of the teardown fails, the account's rows are set to remove_failed — the red Remove Failed chip — with the AWS error attached, and the account stays in the Enrolled accounts table, so a detector that is still running (and still billing) is never reported as removed. Its cached findings are kept too, because a removal that has not finished should not have its evidence deleted. Click Retry removal on that row to re-attempt the teardown.

info

Removing a single account does not detach Prism's persistent GuardDuty IAM policy (CKPrism-GuardDuty-Permissions) from that account's access role. The policy is only removed when GuardDuty is disabled entirely, and only when that teardown completes cleanly.

Live Auto-Polling​

When any account is in an active phase (pending, enabling, inviting, accepting, or removing), the page polls the server every three seconds and updates the status chips, the deployment progress bar and the tables without requiring a manual refresh. Polling stops on its own as soon as no account is in an active phase.