AWS Security Hub · SSM
SSM.3: SSM associations are non-compliant
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub SSM.3 check?
SSM.3 scrapes State Manager association statuses and fails any managed instance whose latest association execution is anything other than COMPLIANT. An association binds an SSM document (patch baseline, inventory gather, agent config) to target instances on a schedule.
Why does SSM.3 matter?
The association is the contract: "this instance will be patched every Sunday", "this instance will report inventory hourly". A failed association means that contract is silently unmet, so the instance has drifted from its declared configuration. SOC 2 and ISO 27001 explicitly require continuous monitoring and evidence that controls are operating, and a NON_COMPLIANT status is exactly the artifact auditors look for.
How do I fix SSM.3?
- Open the failing association and read its execution history to find which step errored.
- Fix the underlying cause: missing permissions, an unreachable instance, or a bad document parameter.
- Re-run the association and confirm it reports COMPLIANT.
- Alert on association failures so drift surfaces before an audit does.
Remediation script · bash
# 1. AWS Config: bind to the service-linked role, record all resources, then start.
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
aws iam create-service-linked-role --aws-service-name config.amazonaws.com 2>/dev/null || true
aws configservice put-configuration-recorder \
--configuration-recorder "name=default,roleARN=arn:aws:iam::${ACCOUNT}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig,recordingGroup={allSupported=true,includeGlobalResourceTypes=true}"
aws configservice start-configuration-recorder --configuration-recorder-name default
# 2. IAM Access Analyzer: create an external access analyzer in this Region.
aws accessanalyzer create-analyzer --analyzer-name external-access --type ACCOUNT
# 3. Systems Manager: enroll an instance role, then confirm it is managed.
aws iam attach-role-policy --role-name app-instance-role \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws ssm describe-instance-information \
--query 'InstanceInformationList[].{Id:InstanceId,Ping:PingStatus}' --output tableFull walkthrough (console steps, edge cases and verification) in the lesson Enable AWS security tooling (Config, Access Analyzer, SSM).
Is SSM.3 a false positive?
An audit-style association (one that runs a check and reports the result rather than enforcing it) can be NON_COMPLIANT by design: it is correctly flagging an instance you have deliberately exempted (a legacy box that intentionally fails the antivirus or port check), so the failure is the association doing its job, not a broken contract. A freshly launched instance can also show NON_COMPLIANT in the window before the association's first scheduled run completes, and a long-stopped or decommissioning instance will never report COMPLIANT because the agent isn't running to execute the association. Confirm the association reflects a known, accepted state, then suppress the SSM.3 finding for that resource in Security Hub (a suppressed finding with a note explaining the exemption) rather than editing the association to hide the result it is supposed to surface.