Security Hub Control Still Failed After Fix: Why and How

If your fix is in and AWS Security Hub CSPM still shows the control as Failed, open the individual finding, not the control tile. The tile is a rollup that AWS rebuilds once every 24 hours from the previous 24 hours of findings, so it can keep saying Failed after the finding underneath has already flipped to Passed. If the finding itself still says FAILED after its next scheduled check, the AWS Config rule behind it hasn't seen your fix yet, and this post walks the causes from cheapest to most drastic.

Jake lost most of a Saturday to this. His wholesale supplier wanted a security questionnaire back by Friday to keep the volume discount on phone cases, and one line asked whether the shop's small AWS account showed zero failed controls in Security Hub. That account holds the repair-booking site and the customer photo backups. He fixed the problem on Wednesday. On Thursday night the control page still said Failed, and he sent Ethan a message that was mostly capital letters.

Ethan's reply was short: "Which one says Failed, the finding or the tile?" Jake had no idea there were two things. Most people don't, and that gap is exactly why this problem eats weekends.

Three different things are all called Failed

First, a quick translation of the vocabulary, because the whole problem lives in it. AWS Security Hub CSPM is the service that shows you the red Failed label. "CSPM" stands for cloud security posture management, which is a fancy way of saying a health check that compares your AWS settings against a checklist, such as the AWS Foundational Security Best Practices standard. Since December 2, 2025, AWS uses the plain name "AWS Security Hub" for a newer, broader product, and the older posture-checking service became "AWS Security Hub CSPM." Everything in this post is about the posture-checking side.

Now the pieces. A control is one item on the checklist, like "this setting should be turned on." A security check is that item tested against one resource, meaning one bucket, one user, one security group. Every check produces a finding, a small record with its own compliance status: PASSED, FAILED, WARNING, or NOT_AVAILABLE. Then the console rolls all the findings for a control into one control status, and rolls all the control statuses into a security score. Those are three separate numbers on three separate clocks.

Here is the rule that produces most of the confusion. A control shows Failed if at least one of its findings is FAILED. Findings that are archived or suppressed are ignored when the control status is worked out, and everything else counts. So one forgotten bucket in one forgotten Region keeps the whole control red, no matter how many others you fixed.

Think of it like school. Each finding is a test paper. The control status is the report card, which gets printed once per term. If you aced the retake on Wednesday, the paper says A, but the report card in your bag still shows the old grade until the next print run. That isn't the school lying to you. It's the schedule. A bathroom scale that shows last week's number until you step on it again works the same way.

Ethan's opinion on this, which he'll defend to anyone: "The tile is a summary for people who want a mood. If you need the truth, read the finding. It's the only place that tells you what the check itself saw and when."

There's also a fourth thing that people confuse with all three: the workflow status on a finding (New, Notified, Suppressed, Resolved). That's a label you and your team use to track who's looking into what. It has no vote in whether a check passes. It gets its own section later, because clicking it is the most popular wrong turn in this whole topic.

Which of these is happening to you? A two-minute triage

You don't need to read this post top to bottom. Find the row that matches what you see on screen, then jump to the section it points at. If two rows fit, start with the higher one, because it's cheaper to rule out.

Notice what the table is really asking: is the problem on the display side (the rollup hasn't caught up), on the judging side (the check hasn't seen your change), or on the scope side (something you didn't fix is still failing)? Nearly every case falls into one of those three buckets, and the finding is the fastest way to tell them apart.

Step one: open the finding, not the tile

This takes about two minutes and answers the question that decides everything else. You're going to compare two moments in time: when Security Hub CSPM last ran the check, and when you made your fix.

1. Open the control. In the Security Hub CSPM console, choose Controls in the navigation pane, then select your control. Write down the control status at the top and the timestamp that says when it was last updated.
2. Open the Checks tab. It lists the active findings for this control from the past 24 hours and leaves archived findings out. Look at the compliance status of every row, not just the resource you fixed.
3. Open the finding for the resource you fixed. Find the compliance status, the last observed time (when Security Hub CSPM most recently ran the check for that control and resource), the updated time, and the first observed time (when the compliance status most recently changed). If there's a list of status reasons, read it. It often names the exact problem.
4. Compare times. If last observed is before your fix, the check hasn't looked at your change yet, which is a scheduling or recording question. If last observed is after your fix and the finding still says FAILED, the check looked and disagreed, which is a scope or recording question.
5. Read the finding's history. Security Hub CSPM keeps the history of a finding, including earlier compliance statuses, so you can see whether it ever flipped to PASSED and back.

Everything above can also be done from the AWS CLI. The CLI (command line interface) is a text tool that sends the same requests the console sends, which is handy when you have several Regions or accounts to look at. Remember that Security Hub CSPM is Regional. A Region is a geographic location where AWS runs your resources, such as us-east-1, and each one keeps its own findings unless you've set up an aggregation Region, which we'll get to.

List the control's active findings, replacing CONTROL_ID with the ID shown on the control page:

aws securityhub get-findings --filters '{"ComplianceSecurityControlId":[{"Value":"CONTROL_ID","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}'

Filter values are case sensitive, so type FAILED and ACTIVE in capitals exactly as shown. To narrow the list to the failing ones and print only their resource IDs, add a second filter on the compliance status:

aws securityhub get-findings --filters '{"ComplianceSecurityControlId":[{"Value":"CONTROL_ID","Comparison":"EQUALS"}],"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}' --query 'Findings[].Resources[].Id'

That second command gives you the list you'll want in the straggler section. For the history of one finding, run the get-finding-history command and identify the finding by its product ARN and ID (an ARN is just AWS's long, unique name for something). Each request returns the history for only one finding.

If your finding shows PASSED and a recent last observed time, you're done fixing. The rest is waiting for the rollup, which the clocks section explains. If it still says FAILED, keep reading.

Reading the timestamps: a worked example

Timestamps are where people freeze up, so here is one walked through. The times below are made up purely to illustrate how to read the fields. They're not real data, and Jake's story isn't proof of anything. Only the meaning of each field is.

Imagine Jake changed the setting on Wednesday at 2:10 PM. This is what he might see when he looks on Wednesday evening, then again on Thursday morning.

The field doing the heavy lifting in that middle row is the first observed time, which is when the compliance status most recently changed. The previous compliance status field records what the finding was before its latest update. Together they tell you whether and when the flip happened, without any guessing.

One more habit worth stealing from Ethan: write your own fix time down. Jake's first instinct was "I fixed it Wednesday, so somewhere around then." Ethan made him find the exact minute in his change log. "If you can't say when you fixed it, you can't say whether the check has seen it," he said. "It's the same reason a mechanic writes down the mileage."

The clocks: what actually runs when

To understand the waiting, you need one more piece of vocabulary. AWS Config is the service that does the actual judging behind the scenes. It has a configuration recorder, which works like a camera that photographs the settings of your resources (each photo is called a configuration item), and rules, which work like judges who look at the photos and say compliant or noncompliant. Security Hub CSPM leans on that machinery. For most controls it creates its own copies of AWS Config rules in your account, called service-linked rules. Their names start with "securityhub," followed by the original rule name and a unique ID, for example securityhub-vpc-flow-logs-enabled-12345. It creates them even when your account already has a rule of the same kind.

Each check follows one of two schedules, and the control's documentation page tells you which (look for "Schedule type"):

• Change-triggered. The check runs when the resource changes state. Think of a smoke alarm: nothing happens until something changes.
• Periodic. The check runs automatically within 12 or 24 hours after the most recent run. Security Hub CSPM picks the interval and you can't change it. Think of a nightly building inspection.

Periodic checks reflect the resource at the moment the check runs, so a fix made an hour ago simply waits for the next inspection. Change-triggered checks depend on the camera. AWS Config lets you choose continuous recording, which photographs every change as it happens, or daily recording, which delivers the state at the end of each 24-hour period, and only if something changed. With daily recording, findings for change-triggered controls can be delayed until that 24-hour period ends. Regardless of your choice, Security Hub CSPM also checks at least once every 24 hours in case it missed an update from AWS Config.

Then come the two display clocks. The control status is rebuilt every 24 hours from the previous 24 hours of findings, and the security score refreshes every 24 hours as well. Both show a timestamp, so you can always see how stale they are. It's the sign on a shop door: you locked up at 6:00, but the sign still says Open until somebody walks over and flips it. Nobody lied. The sign just runs on a person's schedule, not the shop's.

Each of these clocks runs separately, and nothing promises how they line up. So don't plan around an hour. Plan around a day, maybe two, and use the finding's last observed time as your first real signal. If you're building a deadline around this, such as a supplier form or an audit, leave yourself that buffer and don't wait until the night before.

One more piece of timing: when you first enable a standard, checks begin within two hours, and most begin within 25 minutes. Until a control finishes its first run, its status is No data. That matters in the section on Unknown and No data. Also, if you enable a second standard that includes a control already running under the same service-linked rule, findings for the second one can take up to 24 hours to appear.

Jake pushed back here. "So the honest answer is 'wait a day'? I have a Friday deadline." Ethan didn't budge: "The honest answer is 'read the finding, and if it says PASSED, you already have your proof.' Waiting only applies to the tile."

Cause: one straggler is still failing

This is the most common reason a fix looks like it did nothing. A control is Failed if even one finding is FAILED, and findings come from more places than you might expect.

Another resource in the same Region

A control covers every resource of its type, not just the one you touched. If the control says "buckets should have X," then every bucket that lacks X produces its own FAILED finding. Run the second command from earlier and count the IDs. If there are more than you expected, you've found your answer.

Another account or Region

If you're looking at a Security Hub CSPM administrator account, the control status reflects the administrator account and all member accounts, and shows Failed if there's a failed finding in any of them. If you've set an aggregation Region, meaning one chosen Region that pulls findings in from other linked Regions, the control status there covers all the linked Regions in the same way. When you fix something in one Region and stare at the aggregated view in another, the leftover failure may be sitting in a Region you haven't opened in months. The multi-account section below has more on this.

A brand-new resource that repeats the mistake

This one hurts. You fix the bucket, and an hour later your deployment pipeline or template creates a new one with the same misconfiguration. The new resource gets its own FAILED finding. Ethan's opinion, delivered with feeling: "Fixing the instance without fixing the template is bailing water without plugging the hole." Nothing can tell you where your template lives, so this one is on you: after you fix a resource, find what created it.

A resource that changed after your fix

Change-triggered checks run again whenever the resource changes state. If someone, or some automation, changes the setting back, the finding flips to FAILED again. If it had been marked Resolved, Security Hub CSPM resets the workflow status to New, because a PASSED-to-FAILED change means more investigation is needed. Check the finding's history for a PASSED followed by a FAILED. That pattern means something reverted your work, and it's worth finding out what before you fix it a third time.

Cause: AWS Config isn't seeing your fix

If the resource really is fixed and no other resource is failing, the next suspect is the camera. The judge can only rule on the photos it has, and it re-judges old photos just as happily as new ones.

Is the recorder set to daily?

With daily recording, AWS Config delivers the resource state at the end of each 24-hour period, and only if something changed. It's like a parts courier who only comes at 5 PM: whatever Jake ordered at 9 AM still waits for the truck. That can hold back findings for change-triggered controls until the period closes. If you need faster feedback, continuous recording removes that delay. Recording frequency is priced differently, so look at AWS Config pricing before switching a whole account over. You can also override the frequency for specific resource types instead of changing everything.

Is that resource type being recorded at all?

If AWS Config isn't recording the resource type a control checks, Security Hub CSPM can't judge it. A resource type you never recorded, or stopped recording, produces a WARNING finding that doesn't evaluate the resource's real configuration. If you turn recording off for a type that was previously evaluated, Security Hub CSPM keeps the old findings and changes their compliance status to WARNING. Those retained findings may not match what your resource looks like today.

The control that watches for this is Config.1. It produces FAILED findings when AWS Config is disabled, when recording is off, or when recording isn't turned on for a resource type that an enabled control checks. In that last case you also get WARNING findings for the controls that depend on the missing type. One exception: when both Security Hub CSPM and Security Hub are enabled, Security Hub CSPM creates a service-linked configuration recorder called AWSConfigurationRecorderForSecurityHubCSPM, and Config.1 always shows PASSED.

Is the recorder using the right role?

Config.1 also fails if the recorder uses a custom IAM role instead of the AWS Config service-linked role (named AWSServiceRoleForConfig), unless the includeConfigServiceLinkedRoleCheck parameter is set to false. The reason is that other roles might not have the permissions AWS Config needs to record your resources accurately. IAM (Identity and Access Management) is the AWS system that decides who and what is allowed to do things. Also make sure no IAM policy or AWS Organizations policy blocks AWS Config from recording. Note that Security Hub CSPM controls read resource configurations directly and don't take Organizations policies into account, so a policy can quietly starve the recorder while the controls behave as if nothing is wrong.

Are global resources recorded somewhere?

To receive every control finding, AWS Config must also record global resources such as IAM. To keep costs down, the recommendation is to record global resources in only one Region, your home Region if you use cross-Region aggregation or central configuration.

Ask the rule how it's doing, and optionally re-run it

1. Find the rule. In the AWS Config console, open the Rules page and look for names starting with "securityhub." The control's documentation page also names the underlying rule. You can view these rules but not edit or delete them.
2. Read its evaluation status. Run the first command below with the rule name. Look at LastSuccessfulEvaluationTime, LastFailedEvaluationTime, LastErrorCode, and LastErrorMessage. An error message such as "additional permissions needed" means the role AWS Config is using can't evaluate the rule.
3. Optionally re-run it. Use the second command below. Read the next paragraph before you count on it.

aws configservice describe-config-rule-evaluation-status --config-rule-names RULE_NAME

aws configservice start-config-rules-evaluation --config-rule-names RULE_NAME

Two honest caveats. First, the status command doesn't return anything for AWS Config custom Lambda rules, so an empty answer for a control built on one of Security Hub CSPM's custom checks proves nothing. Second, the re-run command runs an on-demand evaluation against the last known configuration state of your resources. It does not re-record the latest state. Ethan's analogy: "Re-running the rule is like re-grading an exam against the answers you handed in, not the ones you corrected since." If your fix hasn't been recorded yet, a re-run judges the old photo. Also, service-linked rules belong to the service that created them, and three calls are blocked on them: PutConfigRule, DeleteConfigRule, and DeleteEvaluationResults. It doesn't say how a Security Hub CSPM-owned rule responds to an on-demand re-run. Treat it as an optional try, not a guaranteed button. A previous re-run for the same rule must also finish before you can call the API again, and each request can name up to 25 rules.

Why AWS Config might show nothing useful

If you have both Security Hub CSPM and Security Hub enabled, you can see the service-linked rules in AWS Config but you won't see the compliant or noncompliant resources for them. Those results appear only in Security Hub CSPM and Security Hub. And since June 2, 2026, AWS Config supports internal service-linked rules, which let services such as Security Hub CSPM run evaluations independently of your own recorders and rules, with results delivered straight to the service. The practical takeaway: the Config console is no longer a reliable second opinion in every setup. If it looks quiet, that may be by design, not a sign of trouble.

When it isn't really Failed: Unknown, No data, and WARNING

Sometimes the tile isn't red at all, and the real problem is that the check can't reach a verdict. A control shows Unknown when at least one finding is WARNING or NOT_AVAILABLE and none are FAILED. It shows No data when it has no findings to judge from. Neither is a pass, and both need a different fix than a failing setting does.

The finding's status reasons list tells you why. Here are the ones you're most likely to meet:

No data after a fix

A control with No data has no findings to judge from. Common reasons: it was newly enabled and hasn't finished its first run (first checks begin within two hours, though a newly enabled control can occasionally take up to 18 hours), every one of its findings is suppressed, or the control isn't available in that Region. Some CIS controls also show No data outside the Region and account where the CloudTrail trail or centralized S3 bucket lives, because the check only runs where those resources are.

When the whole standard is stuck

If every control in a standard shows No data, check whether the standard is in an INCOMPLETE state by running aws securityhub get-enabled-standards --standards-subscription-arn STANDARDS_SUBSCRIPTION_ARN. That state means Security Hub CSPM couldn't create all the controls in the standard, either because the recorder isn't active or because of a passing problem such as throttling. Security Hub CSPM retries roughly every 12 hours until the status becomes READY. The first step is to make sure the recorder is on and configured correctly.

A deleted resource

If you had a resource and deleted it, Security Hub CSPM creates a NOT_AVAILABLE finding and archives it immediately. After 18 hours you get a PASSED finding, because you no longer have a resource for that control. If you have no resources for a control at all, Security Hub CSPM produces a PASSED finding at the account level.

Resolved, Suppressed, Archived: what your clicks actually do

Every finding has a workflow status, a label that tracks your investigation: NEW, NOTIFIED, SUPPRESSED, or RESOLVED. Changing it is a note to yourself and your team. It doesn't change what the check found. Workflow status is specific to an individual finding and doesn't affect the generation of new findings, so setting a finding to Resolved or Suppressed doesn't stop Security Hub CSPM from generating a new finding for the same issue.

Here's how the statuses behave:

• PASSED sets RESOLVED for you. When a control finding's compliance status is PASSED, Security Hub CSPM sets the workflow status to RESOLVED automatically. You don't need to click anything.
• RESOLVED and NOTIFIED reset to NEW when the compliance status changes from PASSED to FAILED, WARNING, or NOT_AVAILABLE, or when the record state changes from ARCHIVED to ACTIVE.
• SUPPRESSED stays put if a finding goes from archived to active.
• Changes take a few minutes. When you change a workflow status yourself, it can take several minutes for Security Hub CSPM to process it. You can add a note explaining why when you set it, which is worth doing.

Archived is different again. Security Hub CSPM archives a finding when its control is disabled, when the resource is deleted or no longer exists, when the finding hasn't been updated in 3 to 5 days (on a best-effort basis), or when the AWS Config evaluation returned NOT_APPLICABLE. Archived findings are ignored when the control status is worked out, and they're stored for 30 days, counted from the finding's updated time, before they're permanently deleted. If you need them longer, you can export findings to an S3 bucket using a custom action with an Amazon EventBridge rule.

If your goal is to reduce noise for test accounts or specific resources, Security Hub CSPM automation rules can update or suppress specific findings automatically. If a control simply doesn't apply to your organization, I recommend disabling the control instead of suppressing its findings. Disabled controls aren't checked and aren't charged.

Cause: the mixed-state windows

Some account settings shuffle your findings around, and for up to a day afterward you can see old and new records side by side. If you or a teammate changed any of these recently, that could explain a stuck label. It's a bit like a shop rearranging its shelves: for a few hours, some things are in the old spot and some are in the new one, and nobody's wrong.

Consolidated control findings

When consolidated control findings is on, Security Hub CSPM generates one finding per check even if the control belongs to several enabled standards. When it's off, you get one finding per standard, so a control shared by four standards produces four findings. Accounts that enabled Security Hub CSPM on or after February 23, 2023 have it on automatically, and older accounts can turn it on. After you switch it either way, it can take up to 24 hours to generate the new findings and archive the old ones. During that time you may see a mix of both kinds, and your security scores can take up to 24 hours to update.

You change this in the console under Settings, then General, then the Controls section, using the Consolidated control findings switch. You need to be in an administrator or standalone account. For member accounts, the setting follows the administrator account.

Aggregation Region changes

Enabling a new aggregation Region or updating the linked Regions resets existing security scores. It can take up to 24 hours for new scores to appear with data from the updated Regions. A score that suddenly looks worse after that change usually reflects the wider coverage, not a new problem.

Disabling a control

The findings of a disabled control may still show a compliance status for up to 24 hours after you disable it. The control's status changes to Disabled, and existing findings are archived automatically, typically within 3 to 5 days on a best-effort basis.

Which "Security Hub" are you in?

Because the older posture-checking service became Security Hub CSPM, the console and documentation can show either name. If your screen says "Security Hub CSPM" and shows controls, standards, and security scores, you're in the right place for this post. Pages about exposures and attack paths belong to the newer, broader product and use different views.

Multi-account and multi-Region setups: where stragglers hide

If your setup is one account and one Region, skim this section. If you're in an organization with member accounts, the same fix can look perfect in one place and broken in another, and here is how.

• AWS Config has to be on everywhere. For Security Hub CSPM to produce control findings, AWS Config must be enabled in each Region where Security Hub CSPM is enabled, and for a multi-account environment that includes the administrator account and every member account.
• Aggregation needs recording in the right places. If you use cross-Region aggregation, AWS Config recording must be configured correctly in the home Region and all linked Regions. Global resources don't need to be recorded in the linked Regions, only in one.
• The administrator's view is a union. As covered earlier, a control looks Failed in the administrator account if any member account has a failed finding.
• Consolidated findings follow the administrator. Member accounts get consolidated control findings only if the administrator account has it, and central configuration policies can't be used to turn it on or off.
• Central configuration can re-create rules. If you use central configuration and Security Hub CSPM can't create its rules because AWS Config isn't enabled, it tries again each time you associate a configuration policy that enables a standard with accounts, organizational units, or the root.

There's also a scheduled retry when rules can't be created. If you enable a standard before AWS Config is enabled, Security Hub CSPM tries to create the service-linked rules on the day you enable the standard, the day after, three days after, and seven days after, then every seven days. That's helpful to know if a member account was onboarded in the wrong order: turning on AWS Config later doesn't necessarily mean an instant result.

Ethan's practical tip for organizations: pick one account and one Region, fix the control there, and let the finding history prove it. Then repeat for the next. "Trying to declare victory across forty accounts at once is how you end up with forty half-answers," he said. Jake, who manages exactly one account, said he was suddenly grateful.

Watch for regressions so you never do this dance twice

Once you've fixed a control, you want to hear about it the moment it goes wrong again, not when someone reads the dashboard on a Friday. Security Hub CSPM sends all new findings and all updates to existing findings to Amazon EventBridge in near real time. EventBridge is AWS's message router: you write a rule that says "when an event looks like this, do that," and the "that" can be a notification, a Lambda function (a small piece of code AWS runs for you), a Step Functions workflow, or a Systems Manager Automation runbook.

The event pattern for these findings always names the source, aws.securityhub, and the detail type, Security Hub Findings - Imported, and can filter on any finding attribute. Here is a pattern that fits the "it broke again" case, using the compliance status and previous compliance status fields:

{"source":["aws.securityhub"],"detail-type":["Security Hub Findings - Imported"],"detail":{"findings":{"Compliance":{"Status":["FAILED"]},"ProductFields":{"PreviousComplianceStatus":["PASSED"]}}}}

A few things worth knowing before you build it:

• Your own clicks fire events too. These events are triggered by updates from both the BatchImportFindings and BatchUpdateFindings operations, so changing a workflow status can generate an event. Filtering on compliance status, as above, keeps you from being paged by your own housekeeping.
• Use the right detail type. The newer Security Hub product also sends findings to EventBridge under the same source but a different detail type. AWS advises using the detail type specific to the product you mean to avoid duplicate notifications.
• One feed for many accounts. The EventBridge feed in your administrator account and aggregation Region includes findings across member accounts and linked Regions, so you can build one rule there instead of many.
• Start with alerts, not auto-fixes. AWS offers a prepackaged solution called Automated Security Response on AWS that can create fully automated response and remediation actions. That's powerful, but a rule that changes your resources automatically deserves a careful rollout, and my advice is to give the people and roles that touch EventBridge least-privilege permissions.

This is also the answer to the "adjacent task" you'll have thirty seconds after your fix works: proving to yourself, and to anyone else, that it stays fixed. A rule like this turns "somebody should check" into a message that arrives on its own.

The escalation ladder: cheapest to most drastic

Most posts about this problem jump straight to the last rung, turning things off and on. That's popular advice, and it's often wrong to start there. Work the ladder from the top.

1. Read the finding and wait one cycle. If it's PASSED and recent, you're done. If it's FAILED and last observed is older than your fix, give the schedule time to run: up to 12 or 24 hours for periodic controls, and up to a day if daily recording is on.
2. Hunt the stragglers. List the failing resources in every account and Region the control covers.
3. Confirm recording. Check Config.1, the recorded resource types, and the recorder's role. Fix anything that produces WARNING or NOT_AVAILABLE.
4. Read the rule's evaluation status. Look for error codes. Optionally, try an on-demand re-run, knowing it judges the last recorded state.
5. Fix the cause, not the instance. If a template or automation keeps recreating the problem, correct it there so new resources start compliant.
6. Disable and re-enable one control. Disabling a control across all standards stops its checks and removes the AWS Config rules Security Hub CSPM created for it; existing findings are archived within about 3 to 5 days. Use this when the control is truly irrelevant, or when you've fixed a recorder problem and want the control's rule rebuilt. Don't use it as a shortcut to a green tile.
7. Turn a whole standard off and on. The last resort. One fix that works: turn off the standard that has no score, wait 20 to 30 minutes, then turn it back on so Security Hub CSPM recreates the required AWS Config rules. Read the warning below first.

Ethan's ruling on rung seven: "If you're reaching for it in the first hour, you haven't read the finding yet."

When nothing works: what to gather before you open a case

Some things you can't fix from your side, and it helps to name them. You can't edit or delete a service-linked rule; to remove one, you disable the standard or control that created it. You can't change the schedule of a periodic check. And you can't make the control tile rebuild faster than its 24-hour cycle. If you've climbed the ladder and the finding is still FAILED with a last observed time after your fix, an AWS Support case is reasonable. Bring evidence, because it shortens the conversation:

• The finding ID and its product ARN, plus the output of the history command for that finding.
• The compliance status, last observed time, updated time, and any status reason codes and descriptions.
• The control ID, the Region, the account, and whether you're in an administrator account or looking at an aggregation Region.
• The rule name and the output of the evaluation-status command, especially any error code and message.
• How the recorder is set up: continuous or daily, which resource types, which role, and whether the service-linked recorder is in use.
• The timestamps: when you made the fix, and the last-updated timestamp on the control page.

Back to Jake's Friday form

Remember Jake and his Thursday-night deadline? The questionnaire asked whether Security Hub showed zero failed controls, and the tile still said Failed. Ethan told him what to write, and it wasn't "yes."

"Write what's true," Ethan said. "The finding for the resource shows PASSED, with the time it was last observed. The control page refreshes on a 24-hour cycle, and here's its last-updated time. Attach the finding details. If your supplier can't work with an honest answer, that's their problem, not the dashboard's."

Jake grumbled that it sounded like a lot of words for one line on a form. Ethan shrugged. "It's also a lot cheaper than explaining next year why a screenshot didn't match." Jake wrote it the honest way, and he didn't suppress anything to make the tile look nicer. The rest is up to the supplier, and to the next check.

Frequently asked questions

How long does Security Hub take to change a control from Failed to Passed?

There's no single number, because three clocks are involved. The finding updates when its check runs: when the resource changes state and AWS Config records it for change-triggered controls, or within 12 or 24 hours of the last run for periodic ones. The control status is then rebuilt every 24 hours from the previous 24 hours of findings, and the security score refreshes on its own 24-hour cycle. Plan for a day or two, and use the finding's last observed time as your first signal.

Why does the finding say PASSED but the control still says Failed?

The control status is derived from the last 24 hours of findings and refreshed every 24 hours, and the control page shows a timestamp for the last update. If your finding's PASSED is newer than that timestamp, the tile is simply behind. Also look at the Checks tab for other FAILED findings on the same control, because one failing resource in any account or Region keeps the whole control Failed, even when your resource is fine.

Can I force Security Hub to re-run a check right now?

There is no run-now option for a control, and the periodic schedule is set by the service and can't be changed. For rule-based controls, the AWS Config StartConfigRulesEvaluation API re-runs a rule against the last recorded state. It's defined for rules in general, and there's no guarantee of how Security Hub CSPM-owned rules respond, so treat it as an optional attempt. It also won't re-record a change AWS Config hasn't captured yet.

Does marking a finding Resolved change the control status?

No. Workflow status tracks your investigation and doesn't affect how findings are generated. Control status comes from compliance status, ignoring only archived and suppressed findings. If the next check comes back FAILED, the workflow status resets to New. When a check returns PASSED, Security Hub CSPM sets the status to RESOLVED on its own, so you rarely need to click it yourself.

Will suppressing the finding make the control pass?

It can change the label, because suppressed findings are ignored when control status is calculated. If you suppress all failed findings, the control becomes Passed, and if every finding is suppressed it shows No data. The problem itself remains, and suppression tells Security Hub CSPM you believe no action is needed. Use it only for accepted risks, with a note explaining why, not to clear a dashboard.

Why does AWS Config show compliant when Security Hub CSPM still shows Failed?

Security Hub CSPM creates its own service-linked rule instances even when you already have similar rules, and since June 2, 2026 it can also use internal service-linked rules that run independently of your recorders and rules. So you may be looking at two separate judges. In accounts with both Security Hub CSPM and Security Hub enabled, the compliant and noncompliant resources for those rules appear only in Security Hub, not in the Config console.

Does my security score update at the same time as the control status?

Both refresh every 24 hours, each with its own timestamp, so they can differ by a few hours. The score is the proportion of Passed controls among enabled controls with data (Passed, Failed, and Unknown count; No data is excluded), shown as a whole-number percentage. In a large set of controls, fixing one may barely move the number, and the score is built from controls, so it isn't affected by findings that aren't controls.

Why does my control say Unknown instead of Passed or Failed?

Unknown means at least one finding is WARNING or NOT_AVAILABLE and none are FAILED. Typical causes are a resource type AWS Config isn't recording, a permissions problem, a rule evaluation error, throttling, or a cross-Region or cross-account resource the rule can't check. Open the finding and read its status reasons; each code names the cause, and the table earlier in this post lists the common ones.

Why do I see No data for a control after fixing it?

No data means there are no findings to judge from. Reasons include a newly enabled control that hasn't finished its first run, every finding being suppressed, or the control not being available in that Region. If every control in a whole standard shows No data, check whether the standard is INCOMPLETE and whether the AWS Config recorder is correctly set up, since that's a different problem from one stubborn control.

Do I need to turn the standard off and back on?

Rarely, and never first. It's a last resort for cases like a standard stuck in INCOMPLETE or missing AWS Config rules. Re-enabling a standard turns on every control that applies to it, including controls you had disabled, because Security Hub CSPM doesn't track which ones you turned off. Work the earlier rungs of the escalation ladder before trying it.

Will disabling a control clear the Failed status?

It stops the checks, so the control shows Disabled, existing findings are archived typically within 3 to 5 days, and the AWS Config rules Security Hub CSPM created for that control are removed. Findings may still show a compliance status for up to 24 hours. That's the right move for a control that truly doesn't apply to you, and the wrong move as a way to get a green tile.

Does daily recording in AWS Config slow Security Hub down?

It can, for change-triggered controls. With daily recording, AWS Config delivers resource state at the end of each 24-hour period if something changed, which can delay findings until the period ends. Security Hub CSPM still checks at least once every 24 hours. Continuous recording avoids the delay but is priced differently, so review AWS Config pricing before switching an account or a resource type.

I fixed the resource in one Region, so why is the control still Failed in my aggregation Region?

The control status in an aggregation Region reflects the aggregation Region and all linked Regions, and it shows Failed if any of them has a failed finding. Administrator accounts also aggregate across member accounts. Open the Checks tab, or list failing findings with the CLI Region by Region, to find the Region or account that still has a FAILED finding.

Why did my Resolved finding go back to New?

Security Hub CSPM resets a finding from Resolved or Notified to New when its compliance status changes from PASSED to FAILED, WARNING, or NOT_AVAILABLE, or when its record state changes from ARCHIVED to ACTIVE. That signals that something changed and deserves another look: the setting may have drifted back, or recording for that resource type may have been turned off.

Can I keep archived findings longer than 30 days?

Security Hub CSPM stores archived control findings for 30 days, measured from the finding's updated time, then permanently deletes them. To keep them longer, export the findings to an S3 bucket by using a custom action with an Amazon EventBridge rule. If you need a record for a supplier or an audit, do that export before the 30 days run out.

When should I contact AWS Support?

Contact them when the finding is still FAILED after its next scheduled check, its last observed time is after your fix, no other resource, account, or Region is failing, the AWS Config recorder is healthy, and the rule's evaluation status shows no errors. Also reach out if an internal service error status reason keeps repeating. Bring the evidence list from the section on what to gather before you open a case.

Revision note. Written September 2026, covering AWS Security Hub CSPM (the posture-checking service formerly called just Security Hub) and the AWS Config service-linked rules and recorders it relies on. This post will change if AWS alters the 24-hour refresh cycle, renames the console labels, or changes how service-linked rules and recorders behave. If you've spent an evening staring at a red label you were sure you'd already fixed, I hope this gave you something solid to go on, and I hope your next check comes back green.