Skip to main content

Security Hub Issues

This page covers common problems with enabling the Security Hub engines (CSPM, GuardDuty, Macie, Inspector, and Detective), enrolling member accounts, managing AWS Config recorders, and refreshing findings.

GuardDuty Member Accounts Stuck in "Failed" Phase​

Problem: After adding member accounts to GuardDuty, one or more accounts remain in the failed phase showing an AccessDenied or "unprocessed" error.

Cause: GuardDuty enrollment sends an invitation to each member account. On first touch, the required IAM role and trust relationships may not have fully propagated to the GuardDuty service in the selected region; AWS IAM changes can take a few minutes to replicate globally, so the initial invitation attempt arrives before the role is ready.

Solution:

  1. On the GuardDuty Enrollment page, locate the account that shows failed status.
  2. Click Retry for that account.
  3. Wait for the retry to complete; the account should transition through inviting and accepting to enabled.
  4. If the account fails again after a retry, verify that the Prism service role has the necessary GuardDuty permissions in the member account and then retry once more.

Root-Email Resolution Times Out When Enrolling Many Accounts (GuardDuty, Macie, Detective)​

Applies to: Amazon GuardDuty, Amazon Macie, and Amazon Detective, the three capabilities that enrol member accounts by invitation and therefore need each account's root email address. It does not apply to CSPM or Amazon Inspector, neither of which uses root emails.

Problem: When adding a large number of member accounts, the root-emails dialog hangs or the request times out (504 Gateway Timeout).

Cause: Root-email resolution runs synchronously during enrollment, one lookup per account, with no caching. Resolving the root email for many accounts at once can exceed the request timeout.

Solution:

  1. Add member accounts in batches of 5 or fewer at a time rather than selecting all accounts and submitting in a single operation.
  2. After each batch completes and those accounts reach enabled status, add the next batch.
  3. This keeps each resolution request well within the timeout window. No other configuration change is needed.
warning

This applies hardest to Amazon Detective. A Detective behavior graph permits up to 1,200 member accounts, so the selections operators attempt there are far larger than a typical GuardDuty enrollment, while the per-account lookup cost is identical and nothing is cached. Detective's setup wizard already chunks its lookups into batches of five and shows a "Resolving root email addresses, N of N accounts" progress line for exactly this reason, but the same batching discipline still applies when adding accounts afterwards from the Detective Enrollment page.

GuardDuty "Enter Root Emails" Dialog / EmailVerificationFailed​

Problem: Prism could not automatically resolve the root email for one or more member accounts and shows a manual entry dialog. After you enter an email and submit, GuardDuty returns EmailVerificationFailed and the invitation does not complete.

Cause: GuardDuty's invitation flow requires the exact root (primary) email address for each member account, the address used when the AWS account was originally created and the one shown under Account Settings in the AWS Console. If the email entered does not match that address, or if a placeholder address was used during account creation, AWS cannot verify ownership and rejects the invitation.

Solution:

  1. In the AWS Console, sign in to the member account and go to Account Settings > Account > Email address; the address shown there is the one GuardDuty requires.
  2. Enter that exact email address in the Prism "Enter root emails" dialog.
  3. Re-submit the enrollment request.
warning

Entering a wrong or placeholder email causes EmailVerificationFailed every time. You must provide the correct root email before the invitation can complete.

Detective Account Shows VERIFICATION_FAILED Minutes After Enrollment Succeeded​

Problem: An Amazon Detective enrollment appeared to succeed, and several minutes later one or more accounts show phase Failed with the AWS status VERIFICATION_FAILED on the Detective Enrollment page. Nothing was reported at the time you submitted.

Cause: Amazon Detective could not match the root email address supplied for that account against the account's actual AWS root user. Detective's invitation call returns success regardless of whether the address is correct; AWS verifies the address asynchronously afterwards, and the account only flips to VERIFICATION_FAILED once that verification fails. The delay is inherent to the flow, which is why the failure surfaces long after the submit screen has gone.

This is usually caused by supplying the account owner's work address, an IAM user's email, a distribution list, or an alias, all of which look plausible and pass Prism's validation.

Solution:

  1. In the AWS Console, sign in to the member account and go to Account Settings > Account > Email address. That exact address is the one Detective requires.
  2. On the Detective Enrollment page, find the failed account. Its row carries an inline root email field pre-filled with the address that was rejected.
  3. Correct the address in that field, then click Retry for that account.
  4. The account re-enters the invitation phases. Verification takes a few minutes; the page polls and updates on its own.
warning

Retrying with the same address fails identically, every time. This is not a transient error, there is nothing to wait out, and no number of retries will clear it. The address must change before the retry can succeed. The inline field exists so the correction can be made at the point of failure, and using Retry without editing it simply reproduces the same result several minutes later.

note

A VERIFICATION_FAILED account is still a member of the behavior graph and still occupies one of its 1,200 member slots, because AWS counts a member from the moment the invitation is created. Either correct and retry it, or remove it from Detective to release the slot. Leaving it in place silently consumes quota that a later enable will be refused over.

Detective Account Shows ACCEPTED_BUT_DISABLED and Is Not Ingesting​

Problem: An account on the Detective Enrollment page shows the AWS status ACCEPTED_BUT_DISABLED, chipped as "Accepted, not ingesting".

Cause: The account has joined the behavior graph, and Amazon Detective is holding it out of ingestion. This is a different situation from a verification failure, which is why the page shows AWS's status beside Prism's phase: the phase reads Failed for both, and only the AWS status can tell them apart. The reason, when Detective supplies one, narrows it further:

ReasonMeaning
VOLUME_UNKNOWNDetective cannot measure the account's data volume. This usually means the account is not enrolled in Amazon GuardDuty.
VOLUME_TOO_HIGHAdding this account's data would push the behavior graph past Amazon Detective's 10 TB/day ingest limit.

Solution:

  1. Use Start monitoring on the account's row. This is the action that applies, not Retry.
  2. For VOLUME_UNKNOWN, enable Amazon GuardDuty for that account first, then click Start monitoring.
  3. For VOLUME_TOO_HIGH, Start monitoring will keep failing until the graph's ingest volume drops below the limit. Remove the highest-volume accounts from Detective, or request a limit increase from AWS Support, and then start monitoring.
warning

Do not use Retry on an ACCEPTED_BUT_DISABLED account. It is already a member of the behavior graph, so re-enrolling it is rejected as a conflict. Start monitoring is the only action that changes anything.

note

Amazon Detective does not always report a reason, and in practice an absent reason is common. When there is none, the row reads "This account joined the behavior graph but Detective is holding it out of the graph. Check the account in the Detective console." Treat the reason as extra information when it is present rather than as something that will always be there. Note also that Amazon GuardDuty is not a prerequisite for enabling Detective at all; it matters only here, as the usual explanation for VOLUME_UNKNOWN.

Standards Show "No Data Yet" or 0% Compliance​

Problem: After enabling Security Hub CSPM and refreshing findings, the compliance dashboard shows standards at 0% or controls show "No data yet" or NO_DATA status.

Cause: Security Hub CSPM standards evaluate resources against controls, and most controls require an active AWS Config recorder in the account and region being evaluated. Without a running recorder, AWS Config cannot supply resource configuration snapshots, so the controls cannot determine compliance.

Solution:

  1. Navigate to AWS Config > Recorders.
  2. Enable a recorder for each account and region where you want compliance scores.
  3. Return to the Compliance Dashboard and click Refresh findings to trigger re-evaluation with the new recording data.
  4. Controls that showed NO_DATA will begin returning results once the recorder has captured at least one configuration snapshot.

AWS Region Missing from the Region Picker​

Problem: A region that exists in AWS is not listed in the region picker when setting up CSPM, GuardDuty, or AWS Config recorders.

Cause: Prism's Security Hub only offers the AWS Regions that are enabled by default in new AWS accounts (sometimes called standard or classic regions). Opt-in regions (such as Asia Pacific (Hyderabad) or the Middle East regions) and special partitions (GovCloud, China) are not listed because they require explicit account-level opt-in and have additional constraints on cross-region aggregation.

Solution: If you need coverage in an opt-in region, contact CloudKeeper support. Managing opt-in regions requires account-level enablement steps outside Security Hub before they can be offered.

note

Amazon Detective is the exception. Its region picker offers the full set of regions where Detective has an endpoint, including five opt-in regions, because whether an opt-in region works is a property of each individual AWS account rather than of the service. If an account has not opted into a region you select, the enablement reports that the region is not enabled for that specific account, naming the account. Two regions, Asia Pacific (Osaka) ap-northeast-3 and Canada West (Calgary) ca-west-1, have no Detective endpoint at all and are never offered.

Partial-Failure Banner Persists After Setup​

Problem: After a Security Hub engine finishes enabling, a partial failure banner appears on the dashboard or enrollment page and does not go away on its own.

Cause: One or more member accounts failed during the enrollment phase, for example, due to an IAM propagation delay, a permission error, a root-email mismatch for GuardDuty or Macie, or a region where the service is not available. The banner reflects that the engine enabled successfully overall but some accounts did not reach the enabled phase.

Partial failure is an expected outcome rather than a broken deployment: the accounts that enrolled are live and producing findings, and nothing is rolled back. Retrying one account never disturbs the others.

Solution:

  1. Click the Review link in the banner, which opens the Enrollment page filtered to the failed accounts.
  2. For each failed account, read the error detail and address the underlying cause (see the GuardDuty failed-phase and root-email entries above as applicable).
  3. Click Retry for each failed account.
  4. Once all accounts reach enabled status, the partial-failure banner clears.

For Amazon Inspector specifically: if the error mentions permissions or AccessDenied, open Amazon Inspector > Settings > Permissions, let the scan complete, and click Fix roles to re-apply the policy to the affected accounts before retrying. If the error names a region, confirm that Amazon Inspector is available there, an unsupported region fails on its own without affecting the rest of the enablement. Note also that Inspector's Granting access phase legitimately runs for several minutes per account while IAM changes propagate; that is not a failure.

For Amazon Detective specifically: read the AWS status chip beside the phase before acting, because the phase reads Failed for two situations with different remedies. VERIFICATION_FAILED needs the address corrected in the row's inline field and then Retry; ACCEPTED_BUT_DISABLED needs Start monitoring and must not be retried. Both are covered in the two Detective entries above. Detective's Granting access and Inviting phases both legitimately run for minutes, the first while IAM changes propagate and the second while AWS verifies each root email address, and neither is a failure.

Progress Bar Frozen on the Progress Screen​

Problem: After submitting a setup wizard, saving settings, or disabling an engine, the progress screen appears but the progress bar stops moving and does not advance.

Cause: The progress screen polls the server at regular intervals to update the bar. If the browser tab was backgrounded, minimized, or if the browser throttled JavaScript timers, the polling loop may have paused or stopped. The server-side operation continues running regardless.

Solution:

  1. Reload the page; the progress screen resumes polling and reflects the current server-side state.
  2. If the bar was at 100% when it froze, the job may already be complete; a reload will route you to the success state.

AWS Config Cell Shows "External" Status​

Problem: One or more cells in the AWS Config Recorders grid show External status and cannot be selected or managed.

Cause: An External cell means an AWS Config recorder already exists in that account-and-region combination, but it was not created by Prism (it was created directly in the AWS Console or by another tool). Prism does not modify or delete recorders it does not own.

Solution: If you want Prism to manage recording for that account and region, delete the external recorder in the AWS Console first, then return to the Prism Recorders grid and enable a new one. If the external recorder is managed by another team or tool, coordinate with them before removing it.

Findings Dashboard Shows "Last Refresh: Never"​

Problem: The Compliance Dashboard (CSPM) or Threat Dashboard (GuardDuty) shows "Last refresh: never" and no findings are visible.

Cause: Findings are not ingested automatically after setup; you must trigger the first refresh manually. Until a refresh job completes, the dashboard has no data to display.

Solution:

  1. On the dashboard, click Refresh findings.
  2. Wait for the refresh job to complete (progress is shown in-page).
  3. Once the job finishes, the dashboard populates with current findings and the "Last refresh" timestamp updates.

Compliance Scores Not Updating After Saving Standards​

Problem: You changed the active compliance standards on the CSPM Settings page and saved, but the scores on the Compliance Dashboard have not updated or a warning banner about AWS Config appears.

Cause: When you add a new standard, the controls in that standard need AWS Config to have already recorded resource snapshots before they can produce a score. If Config recording is not active in the relevant account and region, the new standard shows NO_DATA controls and the dashboard displays a Config warning banner.

Solution:

  1. Check whether the Config warning banner is present on the Compliance Dashboard.
  2. If it is, go to AWS Config > Recorders and enable recording for the affected accounts and regions.
  3. After enabling recording, click Refresh findings on the Compliance Dashboard.
  4. Allow approximately 10 minutes for AWS Config to capture a snapshot and for the new controls to begin evaluating.

Empty Organization Services Sidebar Even Though You Have Access​

Problem: You can log in and reach the Security Hub (or CloudTrail) URL, but the sidebar is completely empty; no navigation items appear.

Cause: The Organization Services sidebar is built from a services claim in your signed session token. If your token was issued before Security Hub access was granted to your account, or if access was revoked, the claim is empty and no sidebar items render.

Solution:

  1. Ask your Prism Admin to confirm that Security Hub (and/or CloudTrail) access is toggled on for your account in Preferences > Admin Management.
  2. After the Admin enables access, sign out of Prism and sign back in; this forces a new token with the updated services claim.
  3. If access is confirmed as granted and the sidebar is still empty after a fresh login, see Access & Organization Services Users or contact CloudKeeper support.

"Authentication Required" Card on the Base Domain​

Problem: You navigate to the Prism URL and see a static Authentication Required card rather than the login screen or your usual portal.

Cause: You opened Prism using the base domain without your organization's realm subdomain (for example, prism.cloudkeeper.com instead of yourcompany.prism.cloudkeeper.com). The portal shell serves a static fallback card at the base domain because it cannot determine which realm to authenticate against without the subdomain.

Solution: Use your organization's full realm URL, for example https://yourcompany.prism.cloudkeeper.com. Your Prism Admin or CloudKeeper representative can confirm the correct URL if you do not have it.

Overview or Configuration Page Shows Stuck Loading Skeletons​

Problem: When you open the Security Hub Overview or the Configuration page, the engine stat cards or the Security capabilities panel show loading skeletons that never resolve.

Cause: Security Hub fetches each engine's current status from a capabilities service on page load. If that service does not respond (for example, due to a transient network issue or a backend error), the skeleton placeholders remain on screen indefinitely.

Solution:

  1. Reload the page; in most cases the capabilities service responds successfully on the next attempt.
  2. If the skeletons persist across multiple reloads over several minutes, contact CloudKeeper support with your realm name and the URL you were on.

Still Having Issues?​

If none of the above solutions resolve your Security Hub problem:

  1. Check the per-account status on the Enrollment page for account-specific error messages.
  2. Verify that your AWS accounts are properly onboarded in the Admin Portal under AWS Accounts.
  3. Contact CloudKeeper support with your realm name, the section you were using (CSPM, GuardDuty, Macie, Inspector, Detective, or AWS Config), and the exact error messages you see.