Skip to main content

Security Hub Issues

This page covers common problems with enabling the Security Hub engines (CSPM, GuardDuty, Macie, Inspector, Detective, and IAM Access Analyzer), 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, Amazon Inspector, or AWS IAM Access Analyzer, none 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.

Findings About My Own Organization's Accounts Look Like False Positives​

Problem: IAM Access Analyzer reports external-access findings naming AWS accounts that belong to your own organization. An S3 bucket policy in your logging account grants a role in your production account, and Prism flags it as external access. Nothing is actually exposed to a third party, so the findings read as noise or as a bug.

Cause: Every IAM Access Analyzer analyzer has a zone of trust, and everything outside that zone is reported as external access. AWS offers two scopes for it:

Analyzer scopeZone of trustA grant to another account in your own AWS Organization is…
Account (what Prism creates)The single AWS account the analyzer lives inreported as an external-access finding
OrganizationThe whole AWS Organizationtreated as trusted, and not reported

Prism creates account-scoped analyzers, so any grant that leaves the account (including a grant to another one of your own accounts, in the same organization) is correctly reported as external. The findings are accurate; they are answering a narrower question than you expected.

Why Prism does it this way. An organization-scoped analyzer can only be created by the AWS Organizations management account or by an account registered as a delegated administrator for Access Analyzer. Prism deliberately holds neither. It enables every Security Hub capability through each enrolled account's own switch role, never touches your management account, never registers a delegated administrator, and its CKPrism-AccessAnalyzer-Permissions policy carries no organizations:* action at all. An account-scoped analyzer is the only kind Prism can create inside that boundary.

The practical consequence. Prism's external-access findings are stricter and noisier than what you would see in the AWS console had you enabled an organization analyzer yourself. If your organization is one trust boundary in practice, a large share of your findings will be intra-organization grants you already know about and accept.

Solution:

  1. Read the Principal field before triaging. Open the finding and check the Access section of the detail drawer. A principal that is one of your own account IDs or a role ARN inside your organization is the intra-organization case. A principal that is *, or an account you do not recognise, is the case that needs action.
  2. Prioritise by the Public flag, not by the count. A finding marked Public reaches everyone on the internet and is genuinely external under any zone of trust. Prism rates those Critical or High for exactly that reason. Cross-account findings are rated Medium.
  3. Run an organization analyzer alongside Prism's if you want the organization-wide view. Nothing prevents you creating an organization-scoped analyzer yourself, in the AWS console, from your management account or a delegated administrator. It coexists with Prism's account-scoped analyzers: AWS's quota is one analyzer per type, per account, per region, and an organization analyzer living in a different account does not consume it.
  4. Use Access Analyzer's own archive rules for grants you have accepted. Archive rules are configured per analyzer in the AWS console and suppress matching findings at the source. Prism does not manage them and holds no permission to create them, but a finding AWS has archived under a rule stops being reported, and therefore stops appearing in Prism after the next refresh.
warning

Do not dismiss these as false positives. An intra-organization grant is real cross-account access; an account-scoped analyzer is right to name it. The same grant evaluated against a different zone of trust would simply not be reported. That is a difference in question asked, not a difference in correctness. Treating the whole class as noise is how a genuinely external grant to a third-party account gets ignored along with them.

An Analyzer Already Existed in My Account​

Problem: An account you enrolled in IAM Access Analyzer already had an analyzer (created in the AWS console, by CloudFormation, or by another tool). You expected the enrollment to fail, or to quietly replace what was there, and want to know which happened.

Cause: AWS enforces a quota of one analyzer per type, per account, per region, and it is not adjustable. In an account that already has an external-access analyzer, creating a second one is simply impossible. AWS reports this in two different ways depending on the name:

SituationWhat AWS returns
An analyzer of that type exists under a different nameServiceQuotaExceededException ("Analyzer limit exceeded")
An analyzer of that type exists under the same nameConflictException

Solution: Nothing. Prism adopts the existing analyzer rather than failing. It records the analyzer against the enrollment, reads its findings alongside every other account's, and the account reaches Enabled normally. The Enrollment page marks the cell Adopted, and the finding detail drawer names the analyzer and says whether Prism created or adopted it.

Ownership is decided by a Prism tag on the analyzer, never by a name match, so an analyzer that merely happens to share Prism's naming convention is still treated as yours.

warning

Prism will never delete an adopted analyzer. Not when you remove the account, not when you remove its region, not when you turn unused access off, and not when you disable the capability. Deleting an analyzer in AWS destroys every finding it has ever generated. Those findings are your record, they may predate Prism entirely, and there is no undo and no export.

The consequence to plan for: an adopted analyzer survives every Prism teardown, keeps producing findings, and (if it is an unused-access analyzer) keeps billing at $0.20 per IAM role or user per month until you delete it yourself in the AWS console. If the bill is why you are tearing down, check the AWS console for analyzers Prism has left in place. See What removal leaves behind.

note

An adopted analyzer left in place is never a teardown failure and never holds the configuration in partial_failure. Leaving it is the intended outcome, not an error.

Access Analyzer Status Shows FAILED​

Problem: On the Access Analyzer Enrollment page, a row's AWS status column reads FAILED. Prism's own Status column may still read Enabled.

Cause: The two columns report different things, and both can be true at once:

  • Status is Prism's enrollment phase: how far Prism got. Enabled means Prism successfully created or adopted the analyzer and attached the permissions policy.
  • AWS status is AnalyzerStatus, what AWS IAM Access Analyzer reports about the analyzer resource itself. FAILED means AWS could not bring the analyzer up, or could not keep it running, after it was created.

An Enabled / FAILED row is therefore not a contradiction and not a Prism bug: Prism did its part, and AWS subsequently failed the analyzer. This is why both columns are always shown rather than being merged into one.

AnalyzerStatusMeaningWhat to do
ACTIVEThe analyzer is running and producing findingsNothing
CREATINGAWS is still provisioning itWait. This resolves on its own, usually within a minute or two, and the page polls
FAILEDAWS could not bring the analyzer upRead the StatusReason beneath the chip; see below
DISABLEDThe analyzer exists but is not analyzingCheck the analyzer in the AWS console

StatusReason is AWS's own explanation of a FAILED status, shown beneath the chip when AWS supplies one. It is the thing to read before acting, because the remedy depends entirely on it. The most common reason is that the analyzer's service-linked role, AWSServiceRoleForAccessAnalyzer, is missing or was deleted from the account. Access Analyzer cannot analyze without it.

Solution:

  1. Read the StatusReason on the row. If AWS supplied none, open the analyzer in the AWS console for that account and region; the console shows the same status with more context.
  2. If the reason names the service-linked role, open IAM Access Analyzer > Settings > Permissions, let the scan complete, and click Fix roles. The CKPrism-AccessAnalyzer-Permissions policy carries a scoped iam:CreateServiceLinkedRole permission for access-analyzer.amazonaws.com precisely so the role can be recreated. Then click Retry on the account from the Enrollment page.
  3. If the reason names a quota, an analyzer of that type already exists in the cell. That is the adoption case above, not a failure. See An analyzer already existed in my account.
  4. If the reason names a region, confirm that AWS IAM Access Analyzer is available in that region. An unsupported region fails on its own without affecting the rest of the enablement.
  5. If the status is FAILED with no reason and does not clear after a retry, contact CloudKeeper support with the account ID, the region, and the analyzer's status as shown in the AWS console.
note

A FAILED analyzer produces no findings, and its absence looks exactly like a clean account. An account whose analyzer has failed shows zero findings, which reads identically to an account with nothing to report. Check the AWS status column before concluding that an account is clean. This is the reason the column exists.

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 AWS IAM Access Analyzer specifically: read the AWS status column beside the phase, because an analyzer AWS has failed is a different problem from an enrollment Prism could not finish. See Access Analyzer status shows FAILED. If the error mentions permissions or AccessDenied, open IAM Access Analyzer > Settings > Permissions, let the scan complete, and click Fix roles before retrying. An account whose cell is marked Adopted is not a failure: Prism found an analyzer already there and read it instead of creating one. Access Analyzer's Granting access phase legitimately runs for several minutes per account while IAM changes propagate; that is not a failure either.

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, IAM Access Analyzer, or AWS Config), and the exact error messages you see.