Understanding patch compliance state values

The information about patches for a managed node include a report of the state, or status, of each individual patch.

Note

If you want to assign a specific patch compliance state to a managed node, you can use the put-compliance-items AWS Command Line Interface (AWS CLI) command or the PutComplianceItems API operation. Assigning compliance state isn't supported in the console.

Use the information in the following tables to help you identify why a managed node might be out of patch compliance.

Patch compliance values for Debian Server, Raspberry Pi OS, and Ubuntu Server

For Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Note

Keep the following in mind when you're evaluating the Installed, Installed Other, and Missing status values: If you don't select the Include nonsecurity updates check box when creating or updating a patch baseline, patch candidate versions are limited to patches included in trusty-security (Ubuntu Server 14.04 LTS), xenial-security (Ubuntu Server 16.04 LTS), bionic-security (Ubuntu Server 18.04 LTS), focal-security (Ubuntu Server 20.04 LTS), groovy-security (Ubuntu Server 20.10 STR), jammy-security (Ubuntu Server 22.04 LTS), or debian-security (Debian Server and Raspberry Pi OS). If you do select the Include nonsecurity updates check box, patches from other repositories are considered as well.

Patch state	Description	Compliance status
INSTALLED	The patch is listed in the patch baseline and is installed on the managed node. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the managed node.	Compliant
INSTALLED_OTHER	The patch isn't included in the baseline or isn't approved by the baseline but is installed on the managed node. The patch might have been installed manually, the package could be a required dependency of another approved patch, or the patch might have been included in an InstallOverrideList operation. If you don't specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.	Compliant
INSTALLED_PENDING_REBOOT	INSTALLED_PENDING_REBOOT can mean either of two things: The Patch Manager Install operation applied the patch to the managed node, but the node has not been rebooted since the patch was applied. This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the managed node. For more information, see Parameter name: RebootOption. A patch was installed outside of Patch Manager since the last time the managed node was rebooted.	Non-Compliant
INSTALLED_REJECTED	The patch is installed on the managed node but is specified in a Rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.	Non-Compliant
MISSING	Packages that are filtered through the baseline and not already installed.	Non-Compliant
FAILED	Packages that failed to install during the patch operation.	Non-Compliant

Patch compliance values for other operating systems

For all operating systems besides Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Patch state	Description	Compliance value
INSTALLED	The patch is listed in the patch baseline and is installed on the managed node. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the node.	Compliant
INSTALLED_OTHER¹	The patch isn't in the baseline, but it is installed on the managed node. The patch might have been installed manually, or the package could be a required dependency of another approved patch. If you don't specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.	Compliant
INSTALLED_REJECTED	The patch is installed on the managed node but is specified in a rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.	Non-Compliant
INSTALLED_PENDING_REBOOT	INSTALLED_PENDING_REBOOT can mean either of two things: The Patch Manager Install operation applied the patch to the managed node, but the node has not been rebooted since the patch was applied. This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the managed node. For more information, see Parameter name: RebootOption. A patch was installed outside of Patch Manager since the last time the managed node was rebooted.	Non-Compliant
MISSING	The patch is approved in the baseline, but it isn't installed on the managed node. If you configure the AWS-RunPatchBaseline document task to scan (instead of install), the system reports this status for patches that were located during the scan but haven't been installed.	Non-Compliant
NOT_APPLICABLE¹	The patch is approved in the baseline, but the service or feature that uses the patch isn't installed on the managed node. For example, a patch for a web server service such as Internet Information Services (IIS) would show NOT_APPLICABLE if it was approved in the baseline, but the web service isn't installed on the managed node. A patch can also be marked NOT_APPLICABLE if it has been superseded by a subsequent update. This means that the later update is installed and the NOT_APPLICABLE update is no longer required. Note This compliance state is only reported on Windows Server operating systems.	Not applicable
FAILED	The patch is approved in the baseline, but it couldn't be installed. To troubleshoot this situation, review the command output for information that might help you understand the problem.	Non-Compliant

¹ For patches with the state INSTALLED_OTHER and NOT_APPLICABLE, Patch Manager omits some data from query results based on the describe-instance-patches command, such as the values for Classification and Severity. This is done to help prevent exceeding the data limit for individual nodes in Inventory, a capability of AWS Systems Manager. To view all patch details, you can use the describe-available-patches command.