• The AWS Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

# Working with Patch Manager resources and compliance using the console
<a name="patch-manager-console"></a>

To use Patch Manager, a tool in AWS Systems Manager, complete the following tasks. These tasks are described in more detail in this section.

1. Verify that the AWS predefined patch baseline for each operating system type that you use meets your needs. If it doesn't, create a patch baseline that defines a standard set of patches for that managed node type and set it as the default instead.

1. Organize managed nodes into patch groups by using Amazon Elastic Compute Cloud (Amazon EC2) tags (optional, but recommended).

1. Do one of the following:
   + (Recommended) Configure a patch policy in Quick Setup, a tool in Systems Manager, that lets you install missing patches on a schedule for an entire organization, a subset of organizational units, or a single AWS account. For more information, see [Configure patching for instances in an organization using a Quick Setup patch policy](quick-setup-patch-manager.md).
   + Create a maintenance window that uses the Systems Manager document (SSM document) `AWS-RunPatchBaseline` in a Run Command task type. For more information, see [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).
   + Manually run `AWS-RunPatchBaseline` in a Run Command operation. For more information, see [Running commands from the console](running-commands-console.md).
   + Manually patch nodes on demand using the **Patch now** feature. For more information, see [Patching managed nodes on demand](patch-manager-patch-now-on-demand.md).

1. Monitor patching to verify compliance and investigate failures.

**Topics**
+ [Creating a patch policy](patch-manager-create-a-patch-policy.md)
+ [Viewing patch Dashboard summaries](patch-manager-view-dashboard-summaries.md)
+ [Working with patch compliance reports](patch-manager-compliance-reports.md)
+ [Patching managed nodes on demand](patch-manager-patch-now-on-demand.md)
+ [Working with patch baselines](patch-manager-create-a-patch-baseline.md)
+ [Viewing available patches](patch-manager-view-available-patches.md)
+ [Creating and managing patch groups](patch-manager-tag-a-patch-group.md)
+ [Integrating Patch Manager with AWS Security Hub CSPM](patch-manager-security-hub-integration.md)

# Creating a patch policy
<a name="patch-manager-create-a-patch-policy"></a>

A patch policy is a configuration you set up using Quick Setup, a tool in AWS Systems Manager. Patch policies provide more extensive and more centralized control over your patching operations than is available with other methods of configuring patching. A patch policy defines the schedule and baseline to use when automatically patching your nodes and applications.

For more information, see the following topics:
+ [Patch policy configurations in Quick Setup](patch-manager-policies.md)
+ [Configure patching for instances in an organization using a Quick Setup patch policy](quick-setup-patch-manager.md)

# Viewing patch Dashboard summaries
<a name="patch-manager-view-dashboard-summaries"></a>

The **Dashboard** tab in Patch Manager provides you with a summary view in the console that you can use to monitor your patching operations in a consolidated view. Patch Manager is a tool in AWS Systems Manager. On the **Dashboard** tab, you can view the following:
+ A snapshot of how many managed nodes are compliant and noncompliant with patching rules.
+ A snapshot of the age of patch compliance results for your managed nodes.
+ A linked count of how many noncompliant managed nodes there are for each of the most common reasons for noncompliance.
+ A linked list of the most recent patching operations.
+ A linked list of the recurring patching tasks that have been set up.

**To view patch Dashboard summaries**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Dashboard** tab.

1. Scroll to the section containing summary data that you want to view:
   + **Amazon EC2 instance management**
   + **Compliance summary**
   + **Noncompliance counts**
   + **Compliance reports**
   + **Non-patch policy-based operations**
   + **Non-patch policy-based recurring tasks**

# Working with patch compliance reports
<a name="patch-manager-compliance-reports"></a>

Use the information in the following topics to help you generate and work with patch compliance reports in Patch Manager, a tool in AWS Systems Manager.

The information in the following topics apply no matter which method or type of configuration you're using for your patching operations: 
+ A patch policy configured in Quick Setup
+ A Host Management option configured in Quick Setup
+ A maintenance window to run a patch `Scan` or `Install` task
+ An on-demand **Patch now** operation

**Important**  
Patch compliance reports are point-in-time snapshots generated only by successful patching operations. Each report contains a capture time that identifies when the compliance status was calculated.  
If you have multiple types of operations in place to scan your instances for patch compliance, note that each scan overwrites the patch compliance data of previous scans. As a result, you might end up with unexpected results in your patch compliance data. For more information, see [Identifying the execution that created patch compliance data](patch-manager-compliance-data-overwrites.md).  
To verify which patch baseline was used to generate the latest compliance information, navigate to the **Compliance reporting** tab in Patch Manager, locate the row for the managed node you want information about, and then choose the baseline ID in the **Baseline ID used** column.

**Topics**
+ [Viewing patch compliance results](patch-manager-view-compliance-results.md)
+ [Generating .csv patch compliance reports](patch-manager-store-compliance-results-in-s3.md)
+ [Remediating noncompliant managed nodes with Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identifying the execution that created patch compliance data](patch-manager-compliance-data-overwrites.md)

# Viewing patch compliance results
<a name="patch-manager-view-compliance-results"></a>

Use these procedures to view patch compliance information about your managed nodes.

This procedure applies to patch operations that use the `AWS-RunPatchBaseline` document. For information about viewing patch compliance information for patch operations that use the `AWS-RunPatchBaselineAssociation` document, see [Identifying noncompliant managed nodes](patch-manager-find-noncompliant-nodes.md).

**Note**  
The patch scanning operations for Quick Setup and Explorer use the `AWS-RunPatchBaselineAssociation` document. Quick Setup and Explorer are both tools in AWS Systems Manager.

**Identify the patch solution for a specific CVE issue (Linux)**  
For many Linux-based operating systems, patch compliance results indicate which Common Vulnerabilities and Exposure (CVE) bulletin issues are resolved by which patches. This information can help you determine how urgently you need to install a missing or failed patch.

CVE details are included for supported versions of the following operating system types:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux

**Note**  
By default, CentOS Stream doesn't provide CVE information about updates. You can, however, allow this support by using third-party repositories such as the Extra Packages for Enterprise Linux (EPEL) repository published by Fedora. For information, see [EPEL](https://fedoraproject.org/wiki/EPEL) on the Fedora Wiki.  
Currently, CVE ID values are reported only for patches with a status of `Missing` or `Failed`.

You can also add CVE IDs to your lists of approved or rejected patches in your patch baselines, as the situation and your patching goals warrant.

For information about working with approved and rejected patch lists, see the following topics:
+ [Working with custom patch baselines](patch-manager-manage-patch-baselines.md)
+ [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md)
+ [How patch baseline rules work on Linux-based systems](patch-manager-linux-rules.md)
+ [How patches are installed](patch-manager-installing-patches.md)

**Note**  
In some cases, Microsoft releases patches for applications that don't specify an updated date and time. In these cases, an updated date and time of `01/01/1970` is supplied by default.

## Viewing patching compliance results
<a name="viewing-patch-compliance-results-console"></a>

Use the following procedures to view patch compliance results in the AWS Systems Manager console. 

**Note**  
For information about generating patch compliance reports that are downloaded to an Amazon Simple Storage Service (Amazon S3) bucket, see [Generating .csv patch compliance reports](patch-manager-store-compliance-results-in-s3.md).

**To view patch compliance results**

1. Do one of the following.

   **Option 1** (recommended) – Navigate from Patch Manager, a tool in AWS Systems Manager:
   + In the navigation pane, choose **Patch Manager**.
   + Choose the **Compliance reporting** tab.
   + In the **Node patching details** area, choose the node ID of the managed node for which you want to review patch compliance results. Nodes that are `stopped` or `terminated` will not be displayed here.
   + In the **Details** area, in the **Properties** list, choose **Patches**.

   **Option 2** – Navigate from Compliance, a tool in AWS Systems Manager:
   + In the navigation pane, choose **Compliance**.
   + For **Compliance resources summary**, choose a number in the column for the types of patch resources you want to review, such as **Non-Compliant resources**.
   + Below, in the **Resource** list, choose the ID of the managed node for which you want to review patch compliance results.
   + In the **Details** area, in the **Properties** list, choose **Patches**.

   **Option 3** – Navigate from Fleet Manager, a tool in AWS Systems Manager.
   + In the navigation pane, choose **Fleet Manager**.
   + In the **Managed instances** area, choose the ID of the managed node for which you want to review patch compliance results.
   + In the **Details** area, in the **Properties** list, choose **Patches**.

1. (Optional) In the Search box (![\[The Search icon\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/search-icon.png)), choose from the available filters.

   For example, for Red Hat Enterprise Linux (RHEL), choose from the following:
   + Name
   + Classification
   + State
   + Severity

    For Windows Server, choose from the following:
   + KB
   + Classification
   + State
   + Severity

1. Choose one of the available values for the filter type you chose. For example, if you chose **State**, now choose a compliance state such as **InstalledPendingReboot**, **Failed** or **Missing**.
**Note**  
Currently, CVE ID values are reported only for patches with a status of `Missing` or `Failed`.

1. Depending on the compliance state of the managed node, you can choose what action to take to remedy any noncompliant nodes.

   For example, you can choose to patch your noncompliant managed nodes immediately. For information about patching your managed nodes on demand, see [Patching managed nodes on demand](patch-manager-patch-now-on-demand.md).

   For information about patch compliance states, see [Patch compliance state values](patch-manager-compliance-states.md).

# Generating .csv patch compliance reports
<a name="patch-manager-store-compliance-results-in-s3"></a>

You can use the AWS Systems Manager console to generate patch compliance reports that are saved as a .csv file to an Amazon Simple Storage Service (Amazon S3) bucket of your choice. You can generate a single on-demand report or specify a schedule for generating the reports automatically. 

Reports can be generated for a single managed node or for all managed nodes in your selected AWS account and AWS Region. For a single node, a report contains comprehensive details, including the IDs of patches related to a node being noncompliant. For a report on all managed nodes, only summary information and counts of noncompliant nodes' patches are provided.

After a report is generated, you can use a tool like Amazon Quick to import and analyze the data. Quick is a business intelligence (BI) service you can use to explore and interpret information in an interactive visual environment. For more information, see the [Amazon Quick User Guide](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).

**Note**  
When you create a custom patch baseline, you can specify a compliance severity level for patches approved by that patch baseline, such as `Critical` or `High`. If the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.

You can also specify an Amazon Simple Notification Service (Amazon SNS) topic to use for sending notifications when a report is generated.

**Service roles for generating patch compliance reports**  
The first time you generate a report, Systems Manager creates an Automation assume role named `AWS-SystemsManager-PatchSummaryExportRole` to use for the export process to S3.

**Note**  
If you are exporting compliance data to an encrypted S3 bucket, you must update its associated AWS KMS key policy to provide the necessary permissions for `AWS-SystemsManager-PatchSummaryExportRole`. For instance, add a permission similar to this to your S3 bucket's AWS KMS policy:  

```
{
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey"
    ],
    "Resource": "role-arn"
}
```
Replace *role-arn* with the Amazon Resource Name (ARN) of the created in your account, in the format `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.  
For more information, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide*.

The first time you generate a report on a schedule, Systems Manager creates another service role named `AWS-EventBridge-Start-SSMAutomationRole`, along with the service role `AWS-SystemsManager-PatchSummaryExportRole` (if not created already) to use for the export process. `AWS-EventBridge-Start-SSMAutomationRole` enables Amazon EventBridge to start an automation using the runbook [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

We recommend against attempting to modify these policies and roles. Doing so could cause patch compliance report generation to fail. For more information, see [Troubleshooting patch compliance report generation](#patch-compliance-reports-troubleshooting).

**Topics**
+ [What's in a generated patch compliance report?](#patch-compliance-reports-to-s3-examples)
+ [Generating patch compliance reports for a single managed node](#patch-compliance-reports-to-s3-one-instance)
+ [Generating patch compliance reports for all managed nodes](#patch-compliance-reports-to-s3-all-instances)
+ [Viewing patch compliance reporting history](#patch-compliance-reporting-history)
+ [Viewing patch compliance reporting schedules](#patch-compliance-reporting-schedules)
+ [Troubleshooting patch compliance report generation](#patch-compliance-reports-troubleshooting)

## What's in a generated patch compliance report?
<a name="patch-compliance-reports-to-s3-examples"></a>

This topic provides information about the types of content included in the patch compliance reports that are generated and downloaded to a specified S3 bucket.

### Report format for a single managed node
<a name="patch-compliance-reports-to-s3-examples-single-instance"></a>

A report generated for a single managed node provides both summary and detailed information.

[Download a sample report (single node)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)

Summary information for a single managed node includes the following:
+ Index
+ Instance ID
+ Instance name
+ Instance IP
+ Platform name
+ Platform version
+ SSM Agent version
+ Patch baseline
+ Patch group
+ Compliance status
+ Compliance severity
+ Noncompliant Critical severity patch count
+ Noncompliant High severity patch count
+ Noncompliant Medium severity patch count
+ Noncompliant Low severity patch count
+ Noncompliant Informational severity patch count
+ Noncompliant Unspecified severity patch count

Detailed information for a single managed node includes the following:
+ Index
+ Instance ID
+ Instance name
+ Patch name
+ KB ID/Patch ID
+ Patch state
+ Last report time
+ Compliance level
+ Patch severity
+ Patch classification
+ CVE ID
+ Patch baseline
+ Logs URL
+ Instance IP
+ Platform name
+ Platform version
+ SSM Agent version

**Note**  
When you create a custom patch baseline, you can specify a compliance severity level for patches approved by that patch baseline, such as `Critical` or `High`. If the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.

### Report format for all managed nodes
<a name="patch-compliance-reports-to-s3-examples-all-instances"></a>

A report generated for all managed nodes provides only summary information.

[Download a sample report (all managed nodes)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)

Summary information for all managed nodes includes the following:
+ Index
+ Instance ID
+ Instance name
+ Instance IP
+ Platform name
+ Platform version
+ SSM Agent version
+ Patch baseline
+ Patch group
+ Compliance status
+ Compliance severity
+ Noncompliant Critical severity patch count
+ Noncompliant High severity patch count
+ Noncompliant Medium severity patch count
+ Noncompliant Low severity patch count
+ Noncompliant Informational severity patch count
+ Noncompliant Unspecified severity patch count

## Generating patch compliance reports for a single managed node
<a name="patch-compliance-reports-to-s3-one-instance"></a>

Use the following procedure to generate a patch summary report for a single managed node in your AWS account. The report for a single managed node provides details about each patch that is out of compliance, including patch names and IDs. 

**To generate patch compliance reports for a single managed node**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Compliance reporting** tab.

1. Choose the button for the row of the managed node for which you want to generate a report, and then choose **View detail**.

1. In the **Patch summary** section, choose **Export to S3**.

1. For **Report name**, enter a name to help you identify the report later.

1. For **Reporting frequency**, choose one of the following:
   + **On demand** – Create a one-time report. Skip to Step 9.
   + **On a schedule** – Specify a recurring schedule for automatically generating reports. Continue to Step 8.

1. For **Schedule type**, specify either a rate expression, such as every 3 days, or provide a cron expression to set the report frequency.

   For information about cron expressions, see [Reference: Cron and rate expressions for Systems Manager](reference-cron-and-rate-expressions.md).

1. For **Bucket name**, select the name of an S3 bucket where you want to store the .csv report files.
**Important**  
If you're working in an AWS Region that was launched after March 20, 2019, you must select an S3 bucket in that same Region. Regions launched after that date were turned off by default. For more information and a list of these Regions, see [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in the *Amazon Web Services General Reference*.

1. (Optional) To send notifications when the report is generated, expend the **SNS topic** section, and then choose an existing Amazon SNS topic from **SNS topic Amazon Resource Name (ARN)**.

1. Choose **Submit**.

For information about viewing a history of generated reports, see [Viewing patch compliance reporting history](#patch-compliance-reporting-history).

For information about viewing details of reporting schedules you have created, see [Viewing patch compliance reporting schedules](#patch-compliance-reporting-schedules).

## Generating patch compliance reports for all managed nodes
<a name="patch-compliance-reports-to-s3-all-instances"></a>

Use the following procedure to generate a patch summary report for all managed nodes in your AWS account. The report for all managed nodes indicates which nodes are out of compliance and the numbers of noncompliant patches. It doesn't provide the names or other identifiers of the patches. For these additional details, you can generate a patch compliance report for a single managed node. For information, see [Generating patch compliance reports for a single managed node](#patch-compliance-reports-to-s3-one-instance) earlier in this topic. 

**To generate patch compliance reports for all managed nodes**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Compliance reporting** tab.

1. Choose **Export to S3**. (Don't select a node ID first.)

1. For **Report name**, enter a name to help you identify the report later.

1. For **Reporting frequency**, choose one of the following:
   + **On demand** – Create a one-time report. Skip to Step 8.
   + **On a schedule** – Specify a recurring schedule for automatically generating reports. Continue to Step 7.

1. For **Schedule type**, specify either a rate expression, such as every 3 days, or provide a cron expression to set the report frequency.

   For information about cron expressions, see [Reference: Cron and rate expressions for Systems Manager](reference-cron-and-rate-expressions.md).

1. For **Bucket name**, select the name of an S3 bucket where you want to store the .csv report files.
**Important**  
If you're working in an AWS Region that was launched after March 20, 2019, you must select an S3 bucket in that same Region. Regions launched after that date were turned off by default. For more information and a list of these Regions, see [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in the *Amazon Web Services General Reference*.

1. (Optional) To send notifications when the report is generated, expend the **SNS topic** section, and then choose an existing Amazon SNS topic from **SNS topic Amazon Resource Name (ARN)**.

1. Choose **Submit**.

For information about viewing a history of generated reports, see [Viewing patch compliance reporting history](#patch-compliance-reporting-history).

For information about viewing details of reporting schedules you have created, see [Viewing patch compliance reporting schedules](#patch-compliance-reporting-schedules).

## Viewing patch compliance reporting history
<a name="patch-compliance-reporting-history"></a>

Use the information in this topic to help you view details about the patch compliance reports generated in your AWS account.

**To view patch compliance reporting history**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Compliance reporting** tab.

1. Choose **View all S3 exports**, and then choose the **Export history** tab.

## Viewing patch compliance reporting schedules
<a name="patch-compliance-reporting-schedules"></a>

Use the information in this topic to help you view details about the patch compliance reporting schedules created in your AWS account.

**To view patch compliance reporting history**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Compliance reporting** tab.

1. Choose **View all S3 exports**, and then choose the **Report schedule rules** tab.

## Troubleshooting patch compliance report generation
<a name="patch-compliance-reports-troubleshooting"></a>

Use the following information to help you troubleshoot problems with generating patch compliance report generation in Patch Manager, a tool in AWS Systems Manager.

**Topics**
+ [A message reports that the `AWS-SystemsManager-PatchManagerExportRolePolicy` policy is corrupted](#patch-compliance-reports-troubleshooting-1)
+ [After deleting patch compliance policies or roles, scheduled reports aren't generated successfully](#patch-compliance-reports-troubleshooting-2)

### A message reports that the `AWS-SystemsManager-PatchManagerExportRolePolicy` policy is corrupted
<a name="patch-compliance-reports-troubleshooting-1"></a>

**Problem**: You receive an error message similar to the following, indicating the `AWS-SystemsManager-PatchManagerExportRolePolicy` is corrupted:

```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any 
role that uses it, then try again. Systems Manager recreates the roles and policies 
you have deleted.
```
+ **Solution**: Use the Patch Manager console or AWS CLI to delete the affected roles and policies before generating a new patch compliance report.

**To delete the corrupt policy using the console**

  1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

  1. Do one of the following:

     **On-demand reports** – If the problem occurred while generating a one-time on-demand report, in the left navigation, choose **Policies**, search for `AWS-SystemsManager-PatchManagerExportRolePolicy`, then delete the policy. Next, choose **Roles**, search for `AWS-SystemsManager-PatchSummaryExportRole`, then delete the role.

     **Scheduled reports** – If the problem occurred while generating a report on a schedule, in the left navigation, choose **Policies**, search one at a time for `AWS-EventBridge-Start-SSMAutomationRolePolicy` and `AWS-SystemsManager-PatchManagerExportRolePolicy`, and delete each policy. Next, choose **Roles**, search one at a time for `AWS-EventBridge-Start-SSMAutomationRole` and `AWS-SystemsManager-PatchSummaryExportRole`, and delete each role.

**To delete the corrupt policy using the AWS CLI**

  Replace the *placeholder values* with your account ID.
  + If the problem occurred while generating a one-time on-demand report, run the following commands:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

    If the problem occurred while generating a report on a schedule, run the following commands:

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
    ```

    ```
    aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
    ```

    ```
    aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
    ```

    ```
    aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
    ```

  After completing either procedure, follow the steps to generate or schedule a new patch compliance report.

### After deleting patch compliance policies or roles, scheduled reports aren't generated successfully
<a name="patch-compliance-reports-troubleshooting-2"></a>

**Problem**: The first time you generate a report, Systems Manager creates a service role and a policy to use for the export process (`AWS-SystemsManager-PatchSummaryExportRole` and `AWS-SystemsManager-PatchManagerExportRolePolicy`). The first time you generate a report on a schedule, Systems Manager creates another service role and a policy (`AWS-EventBridge-Start-SSMAutomationRole` and `AWS-EventBridge-Start-SSMAutomationRolePolicy`). These let Amazon EventBridge start an automation using the runbook [AWS-ExportPatchReportToS3 ](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).

If you delete any of these policies or roles, the connections between your schedule and your specified S3 bucket and Amazon SNS topic might be lost. 
+ **Solution**: To work around this problem, we recommend deleting the previous schedule and creating a new schedule to replace the one that was experiencing issues.

# Remediating noncompliant managed nodes with Patch Manager
<a name="patch-manager-noncompliant-nodes"></a>

The topics in this section provide overviews of how to identify managed nodes that are out of patch compliance and how to bring nodes into compliance.

**Topics**
+ [Identifying noncompliant managed nodes](patch-manager-find-noncompliant-nodes.md)
+ [Patch compliance state values](patch-manager-compliance-states.md)
+ [Patching noncompliant managed nodes](patch-manager-compliance-remediation.md)

# Identifying noncompliant managed nodes
<a name="patch-manager-find-noncompliant-nodes"></a>

Out-of-compliance managed nodes are identified when either of two AWS Systems Manager documents (SSM documents) are run. These SSM documents reference the appropriate patch baseline for each managed node in Patch Manager, a tool in AWS Systems Manager. They then evaluate the patch state of the managed node and then make compliance results available to you.

There are two SSM documents that are used to identify or update noncompliant managed nodes: `AWS-RunPatchBaseline` and `AWS-RunPatchBaselineAssociation`. Each one is used by different processes, and their compliance results are available through different channels. The following table outlines the differences between these documents.

**Note**  
Patch compliance data from Patch Manager can be sent to AWS Security Hub CSPM. Security Hub CSPM gives you a comprehensive view of your high-priority security alerts and compliance status. It also monitors the patching status of your fleet. For more information, see [Integrating Patch Manager with AWS Security Hub CSPM](patch-manager-security-hub-integration.md). 


|  | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` | 
| --- | --- | --- | 
| Processes that use the document |  **Patch on demand** - You can scan or patch managed nodes on demand using the **Patch now** option. For information, see [Patching managed nodes on demand](patch-manager-patch-now-on-demand.md). **Systems Manager Quick Setup patch policies** – You can create a patching configuration in Quick Setup, a tool in AWS Systems Manager, that can scan for or install missing patches on separate schedules for an entire organization, a subset of organizational units, or a single AWS account. For information, see [Configure patching for instances in an organization using a Quick Setup patch policy](quick-setup-patch-manager.md). **Run a command** – You can manually run `AWS-RunPatchBaseline` in an operation in Run Command, a tool in AWS Systems Manager. For information, see [Running commands from the console](running-commands-console.md). **Maintenance window** – You can create a maintenance window that uses the SSM document `AWS-RunPatchBaseline` in a Run Command task type. For information, see [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).  |  **Systems Manager Quick Setup Host Management** – You can enable a Host Management configuration option in Quick Setup to scan your managed instances for patch compliance each day. For information, see [Set up Amazon EC2 host management using Quick Setup](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)** – When you allow Explorer, a tool in AWS Systems Manager, it regularly scans your managed instances for patch compliance and reports results in the Explorer dashboard.  | 
| Format of the patch scan result data |  After `AWS-RunPatchBaseline` runs, Patch Manager sends an `AWS:PatchSummary` object to Inventory, a tool in AWS Systems Manager. This report is generated only by successful patching operations and includes a capture time that identifies when the compliance status was calculated.  |  After `AWS-RunPatchBaselineAssociation` runs, Patch Manager sends an `AWS:ComplianceItem` object to Systems Manager Inventory.  | 
| Viewing patch compliance reports in the console |  You can view patch compliance information for processes that use `AWS-RunPatchBaseline` in [Systems Manager Configuration Compliance](systems-manager-compliance.md) and [Working with managed nodes](fleet-manager-managed-nodes.md). For more information, see [Viewing patch compliance results](patch-manager-view-compliance-results.md).  |  If you use Quick Setup to scan your managed instances for patch compliance, you can see the compliance report in [Systems Manager Fleet Manager](fleet-manager.md). In the Fleet Manager console, choose the node ID of your managed node. In the **General** menu, choose **Configuration compliance**. If you use Explorer to scan your managed instances for patch compliance, you can see the compliance report in both Explorer and [Systems Manager OpsCenter](OpsCenter.md).  | 
| AWS CLI commands for viewing patch compliance results |  For processes that use `AWS-RunPatchBaseline`, you can use the following AWS CLI commands to view summary information about patches on a managed node. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  |  For processes that use `AWS-RunPatchBaselineAssociation`, you can use the following AWS CLI command to view summary information about patches on an instance. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html)  | 
| Patching operations |  For processes that use `AWS-RunPatchBaseline`, you specify whether you want the operation to run a `Scan` operation only, or a `Scan and install` operation. If your goal is to identify noncompliant managed nodes and not remediate them, run only a `Scan` operation.  | Quick Setup and Explorer processes, which use AWS-RunPatchBaselineAssociation, run only a Scan operation. | 
| More info |  [SSM Command document for patching: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)  |  [SSM Command document for patching: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)  | 

For information about the various patch compliance states you might see reported, see [Patch compliance state values](patch-manager-compliance-states.md)

For information about remediating managed nodes that are out of patch compliance, see [Patching noncompliant managed nodes](patch-manager-compliance-remediation.md).

# Patch compliance state values
<a name="patch-manager-compliance-states"></a>

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

**Tip**  
If you want to assign a specific patch compliance state to a managed node, you can use the [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface (AWS CLI) command or the [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) 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 and Ubuntu Server
<a name="patch-compliance-values-ubuntu"></a>

For Debian Server 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 in the following repositories: .   
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS: `focal-security`
Ubuntu Server 22.04 LTS (`jammy-security`)
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-states.html) In neither case does it mean that a patch with this status *requires* a reboot, only that the node hasn't been rebooted since the patch was installed.  | 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`**  |  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 | 
|  **`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 | 

## Patch compliance values for other operating systems
<a name="patch-compliance-values"></a>

For all operating systems besides Debian Server 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. There are two possible reasons for this: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-states.html)  | 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: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-states.html) In neither case does it mean that a patch with this status *requires* a reboot, only that the node hasn't been rebooted since the patch was installed.  | 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 | 
|  **`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 | 
|  **`NOT_APPLICABLE`**¹  |  *This compliance state is reported only for Windows Server operating systems.* 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.  | Not applicable | 
| AVAILABLE\$1SECURITY\$1UPDATES |  *This compliance state is reported only for Windows Server operating systems.* An available security update patch that is not approved by the patch baseline can have a compliance value of `Compliant` or `Non-Compliant`, as defined in a custom patch baseline. When you create or update a patch baseline, you choose the status you want to assign to security patches that are available but not approved because they don't meet the installation criteria specified in the patch baseline. For example, security patches that you might want installed can be skipped if you have specified a long period to wait after a patch is released before installation. If an update to the patch is released during your specified waiting period, the waiting period for installing the patch starts over. If the waiting period is too long, multiple versions of the patch could be released but never installed. For patch summary counts, when a patch is reported as `AvailableSecurityUpdate`, it will always be included in `AvailableSecurityUpdateCount`. If the baseline is configured to report these patches as `NonCompliant`, it is also included in `SecurityNonCompliantCount`. If the baseline is configured to report these patches as `Compliant`, they are not included in `SecurityNonCompliantCount`. These patches are always reported with an unspecified severity and are never included in the `CriticalNonCompliantCount`.  |  Compliant or Non-Compliant, depending on the option selected for available security updates.  Using the console to create or update a patch baseline, you specify this option in the **Available security updates compliance status** field. Using the AWS CLI to run the [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) or [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) command, you specify this option in the `available-security-updates-compliance-status` parameter.   | 

¹ For patches with the state `INSTALLED_OTHER` and `NOT_APPLICABLE`, Patch Manager omits some data from query results based on the [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 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 tool in AWS Systems Manager. To view all patch details, you can use the [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) command. 

# Patching noncompliant managed nodes
<a name="patch-manager-compliance-remediation"></a>

Many of the same AWS Systems Manager tools and processes you can use to check managed nodes for patch compliance can be used to bring nodes into compliance with the patch rules that currently apply to them. To bring managed nodes into patch compliance, Patch Manager, a tool in AWS Systems Manager, must run a `Scan and install` operation. (If your goal is only to identify noncompliant managed nodes and not remediate them, run a `Scan` operation instead. For more information, see [Identifying noncompliant managed nodes](patch-manager-find-noncompliant-nodes.md).)

**Install patches using Systems Manager**  
You can choose from several tools to run a `Scan and install` operation:
+ (Recommended) Configure a patch policy in Quick Setup, a tool in Systems Manager, that lets you install missing patches on a schedule for an entire organization, a subset of organizational units, or a single AWS account. For more information, see [Configure patching for instances in an organization using a Quick Setup patch policy](quick-setup-patch-manager.md).
+ Create a maintenance window that uses the Systems Manager document (SSM document) `AWS-RunPatchBaseline` in a Run Command task type. For information, see [Tutorial: Create a maintenance window for patching using the console](maintenance-window-tutorial-patching.md).
+ Manually run `AWS-RunPatchBaseline` in a Run Command operation. For information, see [Running commands from the console](running-commands-console.md).
+ Install patches on demand using the **Patch now** option. For information, see [Patching managed nodes on demand](patch-manager-patch-now-on-demand.md).

# Identifying the execution that created patch compliance data
<a name="patch-manager-compliance-data-overwrites"></a>

Patch compliance data represents a point-in-time snapshot from the latest successful patching operation. Each compliance report includes both an execution ID and a capture time that help you identify which operation created the compliance data and when it was generated.

If you have multiple types of operations in place to scan your instances for patch compliance, each scan overwrites the patch compliance data of previous scans. As a result, you might end up with unexpected results in your patch compliance data.

For example, suppose you create a patch policy that scans for patch compliance each day at 2 AM local time. That patch policy uses a patch baseline that targets patches with severity marked as `Critical`, `Important`, and `Moderate`. This patch baseline also specifies a few specifically rejected patches. 

Also suppose that you already had a maintenance window set up to scan the same set of managed nodes each day at 4 AM local time, which you don't delete or deactivate. That maintenance window’s task uses a different patch baseline, one that targets only patches with a `Critical` severity and doesn’t exclude any specific patches. 

When this second scan is performed by the maintenance window, the patch compliance data from the first scan is deleted and replaced with patch compliance from the second scan. 

Therefore, we strongly recommend using only one automated method for scanning and installing in your patching operations. If you're setting up patch policies, you should delete or deactivate other methods of scanning for patch compliance. For more information, see the following topics: 
+ To remove a patching operation task from a maintenance window – [Updating or deregistering maintenance window tasks using the console](sysman-maintenance-update.md#sysman-maintenance-update-tasks) 
+ To delete a State Manager association – [Deleting associations](systems-manager-state-manager-delete-association.md).

To deactivate daily patch compliance scans in a Host Management configuration, do the following in Quick Setup:

1. In the navigation pane, choose **Quick Setup**.

1. Select the Host Management configuration to update.

1. Choose **Actions, Edit configuration**.

1. Clear the **Scan instances for missing patches daily** check box.

1. Choose **Update**.

**Note**  
Using the **Patch now** option to scan a managed node for compliance also results in an overwrite of patch compliance data. 

# Patching managed nodes on demand
<a name="patch-manager-patch-now-on-demand"></a>

Using the **Patch now** option in Patch Manager, a tool in AWS Systems Manager, you can run on-demand patching operations from the Systems Manager console. This means you don’t have to create a schedule in order to update the compliance status of your managed nodes or to install patches on noncompliant nodes. You also don’t need to switch the Systems Manager console between Patch Manager and Maintenance Windows, a tool in AWS Systems Manager, in order to set up or modify a scheduled patching window.

**Patch now** is especially useful when you must apply zero-day updates or install other critical patches on your managed nodes as soon as possible.

**Note**  
Patching on demand is supported for a single AWS account-AWS Region pair at a time. It can't be used with patching operations that are based on *patch policies*. We recommend using patch policies for keeping all your managed nodes in compliance. For more information about working with patch policies, see [Patch policy configurations in Quick Setup](patch-manager-policies.md).

**Topics**
+ [How 'Patch now' works](#patch-on-demand-how-it-works)
+ [Running 'Patch now'](#run-patch-now)

## How 'Patch now' works
<a name="patch-on-demand-how-it-works"></a>

To run **Patch now**, you specify just two required settings:
+ Whether to scan for missing patches only, or to scan *and* install patches on your managed nodes
+ Which managed nodes to run the operation on

When the **Patch now** operation runs, it determines which patch baseline to use in the same way one is selected for other patching operations. If a managed node is associated with a patch group, the patch baseline specified for that group is used. If the managed node isn't associated with a patch group, the operation uses the patch baseline that is currently set as the default for the operating system type of the managed node. This can be a predefined baseline, or the custom baseline you have set as the default. For more information about patch baseline selection, see [Patch groups](patch-manager-patch-groups.md). 

Options you can specify for **Patch now** include choosing when, or whether, to reboot managed nodes after patching, specifying an Amazon Simple Storage Service (Amazon S3) bucket to store log data for the patching operation, and running Systems Manager documents (SSM documents) as lifecycle hooks during patching.

### Concurrency and error thresholds for 'Patch now'
<a name="patch-on-demand-concurrency"></a>

For **Patch now** operations, concurrency and error threshold options are handled by Patch Manager. You don't need to specify how many managed nodes to patch at once, nor how many errors are permitted before the operation fails. Patch Manager applies the concurrency and error threshold settings described in the following tables when you patch on demand.

**Important**  
The following thresholds apply to `Scan and install` operations only. For `Scan` operations, Patch Manager attempts to scan up to 1,000 nodes concurrently, and continue scanning until it has encountered up to 1,000 errors.


**Concurrency: Install operations**  

| Total number of managed nodes in the **Patch now** operation | Number of managed nodes scanned or patched at a time | 
| --- | --- | 
| Fewer than 25 | 1 | 
| 25-100 | 5% | 
| 101 to 1,000 | 8% | 
| More than 1,000 | 10% | 


**Error threshold: Install operations**  

| Total number of managed nodes in the **Patch now** operation | Number of errors permitted before the operation fails | 
| --- | --- | 
| Fewer than 25 | 1 | 
| 25-100 | 5 | 
| 101 to 1,000 | 10 | 
| More than 1,000 | 10 | 

### Using 'Patch now' lifecycle hooks
<a name="patch-on-demand-hooks"></a>

**Patch now** provides you with the ability to run SSM Command documents as lifecycle hooks during an `Install` patching operation. You can use these hooks for tasks such as shutting down applications before patching or running health checks on your applications after patching or after a reboot. 

For more information about using lifecycle hooks, see [SSM Command document for patching: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).

The following table lists the lifecycle hooks available for each of the three **Patch now** reboot options, in addition to sample uses for each hook.


**Lifecycle hooks and sample uses**  

| Reboot option | Hook: Before installation | Hook: After installation | Hook: On exit | Hook: After scheduled reboot | 
| --- | --- | --- | --- | --- | 
| Reboot if needed |  Run an SSM document before patching begins. Example use: Safely shut down applications before the patching process begins.   |  Run an SSM document at the end of the patching operation and before managed node reboot. Example use: Run operations such as installing third-party applications before a potential reboot.  |  Run an SSM document after the patching operation is complete and instances are rebooted. Example use: Ensure that applications are running as expected after patching.  | Not available | 
| Do not reboot my instances | Same as above. |  Run an SSM document at the end of the patching operation. Example use: Ensure that applications are running as expected after patching.  |  *Not available*   |  *Not available*   | 
| Schedule a reboot time | Same as above. | Same as for Do not reboot my instances. | Not available |  Run an SSM document immediately after a scheduled reboot is complete. Example use: Ensure that applications are running as expected after the reboot.  | 

## Running 'Patch now'
<a name="run-patch-now"></a>

Use the following procedure to patch your managed nodes on demand.

**To run 'Patch now'**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose **Patch now**.

1. For **Patching operation**, choose one of the following:
   + **Scan**: Patch Manager finds which patches are missing from your managed nodes but doesn't install them. You can view the results in the **Compliance** dashboard or in other tools you use for viewing patch compliance.
   + **Scan and install**: Patch Manager finds which patches are missing from your managed nodes and installs them.

1. Use this step only if you chose **Scan and install** in the previous step. For **Reboot option**, choose one of the following:
   + **Reboot if needed**: After installation, Patch Manager reboots managed nodes only if needed to complete a patch installation.
   + **Don't reboot my instances**: After installation, Patch Manager doesn't reboot managed nodes. You can reboot nodes manually when you choose or manage reboots outside of Patch Manager.
   + **Schedule a reboot time**: Specify the date, time, and UTC time zone for Patch Manager to reboot your managed nodes. After you run the **Patch now** operation, the scheduled reboot is listed as an association in State Manager with the name `AWS-PatchRebootAssociation`.
**Important**  
If you cancel the main patching operation after it has started, the `AWS-PatchRebootAssociation` association in State Manager is NOT automatically canceled. To prevent unexpected reboots, you must manually delete `AWS-PatchRebootAssociation` from State Manager if you no longer want the scheduled reboot to occur. Failure to do so may result in unplanned system reboots that could impact production workloads. You can find this association in the Systems Manager console under **State Manager** > **Associations**.

1. For **Instances to patch**, choose one of the following:
   + **Patch all instances**: Patch Manager runs the specified operation on all managed nodes in your AWS account in the current AWS Region.
   + **Patch only the target instances I specify**: You specify which managed nodes to target in the next step.

1. Use this step only if you chose **Patch only the target instances I specify** in the previous step. In the **Target selection** section, identify the nodes on which you want to run this operation by specifying tags, selecting nodes manually, or specifying a resource group.
**Note**  
If a managed node you expect to see isn't listed, see [Troubleshooting managed node availability](fleet-manager-troubleshooting-managed-nodes.md) for troubleshooting tips.  
If you choose to target a resource group, note that resource groups that are based on an AWS CloudFormation stack must still be tagged with the default `aws:cloudformation:stack-id` tag. If it has been removed, Patch Manager might be unable to determine which managed nodes belong to the resource group.

1. (Optional) For **Patching log storage**, if you want to create and save logs from this patching operation, select the S3 bucket for storing the logs.
**Note**  
The S3 permissions that grant the ability to write the data to an S3 bucket are those of the instance profile (for EC2 instances) or IAM service role (hybrid-activated machines) assigned to the instance, not those of the IAM user performing this task. For more information, see [Configure instance permissions required for Systems Manager](setup-instance-permissions.md) or [Create the IAM service role required for Systems Manager in hybrid and multicloud environments](hybrid-multicloud-service-role.md). In addition, if the specified S3 bucket is in a different AWS account, make sure that the instance profile or IAM service role associated with the managed node has the necessary permissions to write to that bucket.

1. (Optional) If you want to run SSM documents as lifecycle hooks during specific points of the patching operation, do the following:
   + Choose **Use lifecycle hooks**.
   + For each available hook, select the SSM document to run at the specified point of the operation:
     + Before installation
     + After installation
     + On exit
     + After scheduled reboot
**Note**  
The default document, `AWS-Noop`, runs no operations.

1. Choose **Patch now**.

   The **Association execution summary** page opens. (Patch now uses associations in State Manager, a tool in AWS Systems Manager, for its operations.) In the **Operation summary** area, you can monitor the status of scanning or patching on the managed nodes you specified.

# Working with patch baselines
<a name="patch-manager-create-a-patch-baseline"></a>

A patch baseline in Patch Manager, a tool in AWS Systems Manager, defines which patches are approved for installation on your managed nodes. You can specify approved or rejected patches one by one. You can also create auto-approval rules to specify that certain types of updates (for example, critical updates) should be automatically approved. The rejected list overrides both the rules and the approve list. To use a list of approved patches to install specific packages, you first remove all auto-approval rules. If you explicitly identify a patch as rejected, it won't be approved or installed, even if it matches all of the criteria in an auto-approval rule. Also, a patch is installed on a managed node only if it applies to the software on the node, even if the patch has otherwise been approved for the managed node.

**Topics**
+ [Viewing AWS predefined patch baselines](patch-manager-view-predefined-patch-baselines.md)
+ [Working with custom patch baselines](patch-manager-manage-patch-baselines.md)
+ [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md)

**More info**  
+ [Patch baselines](patch-manager-patch-baselines.md)

# Viewing AWS predefined patch baselines
<a name="patch-manager-view-predefined-patch-baselines"></a>

Patch Manager, a tool in AWS Systems Manager, includes a predefined patch baseline for each operating system supported by Patch Manager. You can use these patch baselines (you can't customize them), or you can create your own. The following procedure describes how to view a predefined patch baseline to see if it meets your needs. To learn more about patch baselines, see [Predefined and custom patch baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**To view AWS predefined patch baselines**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. In the patch baselines list, choose the baseline ID of one of the predefined patch baselines.

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, choose the **Patch baselines** tab, and then choose the baseline ID of one of the predefined patch baselines.
**Note**  
For Windows Server, three predefined patch baselines are provided. The patch baselines `AWS-DefaultPatchBaseline` and `AWS-WindowsPredefinedPatchBaseline-OS` support only operating system updates on the Windows operating system itself. `AWS-DefaultPatchBaseline` is used as the default patch baseline for Windows Server managed nodes unless you specify a different patch baseline. The configuration settings in these two patch baselines are the same. The newer of the two, `AWS-WindowsPredefinedPatchBaseline-OS`, was created to distinguish it from the third predefined patch baseline for Windows Server. That patch baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, can be used to apply patches to both the Windows Server operating system and supported applications released by Microsoft.  
For more information, see [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md).

1. In the **Approval rules** section, review the patch baseline configuration.

1. If the configuration is acceptable for your managed nodes, you can skip ahead to the procedure [Creating and managing patch groups](patch-manager-tag-a-patch-group.md). 

   -or-

   To create your own default patch baseline, continue to the topic [Working with custom patch baselines](patch-manager-manage-patch-baselines.md).

# Working with custom patch baselines
<a name="patch-manager-manage-patch-baselines"></a>

Patch Manager, a tool in AWS Systems Manager, includes a predefined patch baseline for each operating system supported by Patch Manager. You can use these patch baselines (you can't customize them), or you can create your own. 

The following procedures describe how to create, update, and delete your own custom patch baselines. To learn more about patch baselines, see [Predefined and custom patch baselines](patch-manager-predefined-and-custom-patch-baselines.md).

**Topics**
+ [Creating a custom patch baseline for Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Creating a custom patch baseline for macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Creating a custom patch baseline for Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Updating or deleting a custom patch baseline](patch-manager-update-or-delete-a-patch-baseline.md)

# Creating a custom patch baseline for Linux
<a name="patch-manager-create-a-patch-baseline-for-linux"></a>

Use the following procedure to create a custom patch baseline for Linux managed nodes in Patch Manager, a tool in AWS Systems Manager. 

For information about creating a patch baseline for macOS managed nodes, see [Creating a custom patch baseline for macOS](patch-manager-create-a-patch-baseline-for-macos.md). For information about creating a patch baseline for Windows managed nodes, see [Creating a custom patch baseline for Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).

**To create a custom patch baseline for Linux managed nodes**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Patch baselines** tab, and then choose **Create patch baseline**.

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, choose the **Patch baselines** tab, and then choose **Create patch baseline**.

1. For **Name**, enter a name for your new patch baseline, for example, `MyRHELPatchBaseline`.

1. (Optional) For **Description**, enter a description for this patch baseline.

1. For **Operating system**, choose an operating system, for example, `Red Hat Enterprise Linux`.

1. If you want to begin using this patch baseline as the default for the selected operating system as soon as you create it, check the box next to **Set this patch baseline as the default patch baseline for *operating system name* instances**.
**Note**  
This option is available only if you first accessed Patch Manager before the [patch policies](patch-manager-policies.md) release on December 22, 2022.  
For information about setting an existing patch baseline as the default, see [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md).

1. In the **Approval rules for operating-systems** section, use the fields to create one or more auto-approval rules.
   + **Products**: The version of the operating systems the approval rule applies to, such as `RedhatEnterpriseLinux7.4`. The default selection is `All`.
   + **Classification**: The type of patches the approval rule applies to, such as `Security` or `Enhancement`. The default selection is `All`. 
**Tip**  
You can configure a patch baseline to control whether minor version upgrades for Linux are installed, such as RHEL 7.8. Minor version upgrades can be installed automatically by Patch Manager provided that the update is available in the appropriate repository.  
For Linux operating systems, minor version upgrades aren't classified consistently. They can be classified as bug fixes or security updates, or not classified, even within the same kernel version. Here are a few options for controlling whether a patch baseline installs them.   
**Option 1**: The broadest approval rule to ensure minor version upgrades are installed when available is to specify **Classification** as `All` (\$1) and choose the **Include nonsecurity updates** option.
**Option 2**: To ensure patches for an operating system version are installed, you can use a wildcard (\$1) to specify its kernel format in the **Patch exceptions** section of the baseline. For example, the kernel format for RHEL 7.\$1 is `kernel-3.10.0-*.el7.x86_64`.  
Enter `kernel-3.10.0-*.el7.x86_64` in the **Approved patches** list in your patch baseline to ensure all patches, including minor version upgrades, are applied to your RHEL 7.\$1 managed nodes. (If you know the exact package name of a minor version patch, you can enter that instead.)
**Option 3**: You can have the most control over which patches are applied to your managed nodes, including minor version upgrades, by using the [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) parameter in the `AWS-RunPatchBaseline` document. For more information, see [SSM Command document for patching: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
   + **Severity**: The severity value of patches the rule is to apply to, such as `Critical`. The default selection is `All`. 
   + **Auto-approval**: The method for selecting patches for automatic approval.
**Note**  
Because it's not possible to reliably determine the release dates of update packages for Ubuntu Server, the auto-approval options aren't supported for this operating system.
     + **Approve patches after a specified number of days**: The number of days for Patch Manager to wait after a patch is released or last updated before a patch is automatically approved. You can enter any integer from zero (0) to 360. For most scenarios, we recommend waiting no more than 100 days.
     + **Approve patches released up to a specific date**: The patch release date for which Patch Manager automatically applies all patches released or updated on or before that date. For example, if you specify July 7, 2023, no patches released or last updated on or after July 8, 2023, are installed automatically.
   + (Optional) **Compliance reporting**: The severity level you want to assign to patches approved by the baseline, such as `Critical` or `High`.
**Note**  
If you specify a compliance reporting level and the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.
   + **Include non-security updates**: Select the check box to install nonsecurity Linux operating system patches made available in the source repository, in addition to the security-related patches. 

   For more information about working with approval rules in a custom patch baseline, see [Custom baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. If you want to explicitly approve any patches in addition to those meeting your approval rules, do the following in the **Patch exceptions** section:
   + For **Approved patches**, enter a comma-separated list of the patches you want to approve.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) For **Approved patches compliance level**, assign a compliance level to the patches in the list.
   + If any approved patches you specify aren't related to security, select the **Include non-security updates** check box for these patches to be installed on your Linux operating system as well.

1. If you want to explicitly reject any patches that otherwise meet your approval rules, do the following in the **Patch exceptions** section:
   + For **Rejected patches**, enter a comma-separated list of the patches you want to reject.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + For **Rejected patches action**, select the action for Patch Manager to take on patches included in the **Rejected patches** list.
     + **Allow as dependency**: A package in the **Rejected patches** list is installed only if it's a dependency of another package. It's considered compliant with the patch baseline and its status is reported as *InstalledOther*. This is the default action if no option is specified.
     + **Block**: Packages in the **Rejected patches** list, and packages that include them as dependencies, aren't installed by Patch Manager under any circumstances. If a package was installed before it was added to the **Rejected patches** list, or is installed outside of Patch Manager afterward, it's considered noncompliant with the patch baseline and its status is reported as *InstalledRejected*.
**Note**  
Patch Manager searches for patch dependencies recursively.

1. (Optional) If you want to specify alternative patch repositories for different versions of an operating system, such as *AmazonLinux2016.03* and *AmazonLinux2017.09*, do the following for each product in the **Patch sources** section:
   + In **Name**, enter a name to help you identify the source configuration.
   + In **Product**, select the version of the operating systems the patch source repository is for, such as `RedhatEnterpriseLinux7.4`.
   + In **Configuration**, enter the value of the repository configuration to use in the appropriate format:

------
#### [  Example for yum repositories  ]

     ```
     [main]
     name=MyCustomRepository
     baseurl=https://my-custom-repository
     enabled=1
     ```

**Tip**  
For information about other options available for your yum repository configuration, see [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).

------
#### [  Examples for Ubuntu Server and Debian Server ]

      `deb http://security.ubuntu.com/ubuntu jammy main` 

      `deb https://site.example.com/debian distribution component1 component2 component3` 

     Repo information for Ubuntu Server repositories must be specifed in a single line. For more examples and information, see [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) on the *Ubuntu Server Manuals* website and [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format) on the *Debian Wiki*.

------

     Choose **Add another source** to specify a source repository for each additional operating system version, up to a maximum of 20.

     For more information about alternative source patch repositories, see [How to specify an alternative patch source repository (Linux)](patch-manager-alternative-source-repository.md).

1. (Optional) For **Manage tags**, apply one or more tag key name/value pairs to the patch baseline.

   Tags are optional metadata that you assign to a resource. Tags allow you to categorize a resource in different ways, such as by purpose, owner, or environment. For example, you might want to tag a patch baseline to identify the severity level of patches it specifies, the operating system family it applies to, and the environment type. In this case, you could specify tags similar to the following key name/value pairs:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Choose **Create patch baseline**.

# Creating a custom patch baseline for macOS
<a name="patch-manager-create-a-patch-baseline-for-macos"></a>

Use the following procedure to create a custom patch baseline for macOS managed nodes in Patch Manager, a tool in AWS Systems Manager. 

For information about creating a patch baseline for Windows Server managed nodes, see [Creating a custom patch baseline for Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). For information about creating a patch baseline for Linux managed nodes, see [Creating a custom patch baseline for Linux](patch-manager-create-a-patch-baseline-for-linux.md). 

**Note**  
macOS is not supported in all AWS Regions. For more information about Amazon EC2 support for macOS, see [Amazon EC2 Mac instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) in the *Amazon EC2 User Guide*.

**To create a custom patch baseline for macOS managed nodes**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Patch baselines** tab, and then choose **Create patch baseline**.

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, choose the **Patch baselines** tab, and then choose **Create patch baseline**.

1. For **Name**, enter a name for your new patch baseline, for example, `MymacOSPatchBaseline`.

1. (Optional) For **Description**, enter a description for this patch baseline.

1. For **Operating system**, choose macOS.

1. If you want to begin using this patch baseline as the default for macOS as soon as you create it, check the box next to **Set this patch baseline as the default patch baseline for macOS instances**.
**Note**  
This option is available only if you first accessed Patch Manager before the [patch policies](patch-manager-policies.md) release on December 22, 2022.  
For information about setting an existing patch baseline as the default, see [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md).

1. In the **Approval rules for operating-systems** section, use the fields to create one or more auto-approval rules.
   + **Products**: The version of the operating systems the approval rule applies to, such as `BigSur11.3.1` or `Ventura13.7`. The default selection is `All`.
   + **Classification**: The package manager or package managers that you want to apply packages during the patching process. You can choose from the following:
     + softwareupdate
     + installer
     + brew
     + brew cask

     The default selection is `All`. 
   + (Optional) **Compliance reporting**: The severity level you want to assign to patches approved by the baseline, such as `Critical` or `High`.
**Note**  
If you specify a compliance reporting level and the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.

   For more information about working with approval rules in a custom patch baseline, see [Custom baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).

1. If you want to explicitly approve any patches in addition to those meeting your approval rules, do the following in the **Patch exceptions** section:
   + For **Approved patches**, enter a comma-separated list of the patches you want to approve.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) For **Approved patches compliance level**, assign a compliance level to the patches in the list.

1. If you want to explicitly reject any patches that otherwise meet your approval rules, do the following in the **Patch exceptions** section:
   + For **Rejected patches**, enter a comma-separated list of the patches you want to reject.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + For **Rejected patches action**, select the action for Patch Manager to take on patches included in the **Rejected patches** list.
     + **Allow as dependency**: A package in the **Rejected patches** list is installed only if it's a dependency of another package. It's considered compliant with the patch baseline and its status is reported as *InstalledOther*. This is the default action if no option is specified.
     + **Block**: Packages in the **Rejected patches** list, and packages that include them as dependencies, aren't installed by Patch Manager under any circumstances. If a package was installed before it was added to the **Rejected patches** list, or is installed outside of Patch Manager afterward, it's considered noncompliant with the patch baseline and its status is reported as *InstalledRejected*.

1. (Optional) For **Manage tags**, apply one or more tag key name/value pairs to the patch baseline.

   Tags are optional metadata that you assign to a resource. Tags allow you to categorize a resource in different ways, such as by purpose, owner, or environment. For example, you might want to tag a patch baseline to identify the severity level of patches it specifies, the package manager it applies to, and the environment type. In this case, you could specify tags similar to the following key name/value pairs:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=PackageManager,Value=softwareupdate`
   + `Key=Environment,Value=Production`

1. Choose **Create patch baseline**.

# Creating a custom patch baseline for Windows Server
<a name="patch-manager-create-a-patch-baseline-for-windows"></a>

Use the following procedure to create a custom patch baseline for Windows managed nodes in Patch Manager, a tool in AWS Systems Manager. 

For information about creating a patch baseline for Linux managed nodes, see [Creating a custom patch baseline for Linux](patch-manager-create-a-patch-baseline-for-linux.md). Fo information about creating a patch baseline for macOS managed nodes, see [Creating a custom patch baseline for macOS](patch-manager-create-a-patch-baseline-for-macos.md).

For an example of creating a patch baseline that is limited to installing Windows Service Packs only, see [Tutorial: Create a patch baseline for installing Windows Service Packs using the console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).

**To create a custom patch baseline (Windows)**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Patch baselines** tab, and then choose **Create patch baseline**. 

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, choose the **Patch baselines** tab, and then choose **Create patch baseline**.

1. For **Name**, enter a name for your new patch baseline, for example, `MyWindowsPatchBaseline`.

1. (Optional) For **Description**, enter a description for this patch baseline.

1. For **Operating system**, choose `Windows`.

1. For **Available security updates compliance status**, choose the status you want to assign to security patches that are available but not approved because they don't meet the installation criteria specified in the patch baseline, **Non-Compliant** or **Compliant**.

   Example scenario: Security patches that you might want installed can be skipped if you have specified a long period to wait after a patch is released before installation. If an update to the patch is released during your specified waiting period, the waiting period for installing the patch starts over. If the waiting period is too long, multiple versions of the patch could be released but never installed.

1. If you want to begin using this patch baseline as the default for Windows as soon as you create it, select **Set this patch baseline as the default patch baseline for Windows Server instances** .
**Note**  
This option is available only if you first accessed Patch Manager before the [patch policies](patch-manager-policies.md) release on December 22, 2022.  
For information about setting an existing patch baseline as the default, see [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md).

1. In the **Approval rules for operating systems** section, use the fields to create one or more auto-approval rules.
   + **Products**: The version of the operating systems the approval rule applies to, such as `WindowsServer2012`. The default selection is `All`.
   + **Classification**: The type of patches the approval rule applies to, such as `CriticalUpdates`, `Drivers`, and `Tools`. The default selection is `All`. 
**Tip**  
You can include Windows Service Pack installations in your approval rules by including `ServicePacks` or by choosing `All` in your **Classification** list. For an example, see [Tutorial: Create a patch baseline for installing Windows Service Packs using the console](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
   + **Severity**: The severity value of patches the rule is to apply to, such as `Critical`. The default selection is `All`. 
   + **Auto-approval**: The method for selecting patches for automatic approval.
     + **Approve patches after a specified number of days**: The number of days for Patch Manager to wait after a patch is released or updated before a patch is automatically approved. You can enter any integer from zero (0) to 360. For most scenarios, we recommend waiting no more than 100 days.
     + **Approve patches released up to a specific date**: The patch release date for which Patch Manager automatically applies all patches released or updated on or before that date. For example, if you specify July 7, 2023, no patches released or last updated on or after July 8, 2023, are installed automatically.
   + (Optional) **Compliance reporting**: The severity level you want to assign to patches approved by the baseline, such as `High`.
**Note**  
If you specify a compliance reporting level and the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.

1. (Optional) In the **Approval rules for applications** section, use the fields to create one or more auto-approval rules.
**Note**  
Instead of specifying approval rules, you can specify lists of approved and rejected patches as patch exceptions. See steps 10 and 11. 
   + **Product family**: The general Microsoft product family for which you want to specify a rule, such as `Office` or `Exchange Server`.
   + **Products**: The version of the application the approval rule applies to, such as `Office 2016` or `Active Directory Rights Management Services Client 2.0 2016`. The default selection is `All`.
   + **Classification**: The type of patches the approval rule applies to, such as `CriticalUpdates`. The default selection is `All`. 
   + **Severity**: The severity value of patches the rule applies to, such as `Critical`. The default selection is `All`. 
   + **Auto-approval**: The method for selecting patches for automatic approval.
     + **Approve patches after a specified number of days**: The number of days for Patch Manager to wait after a patch is released or updated before a patch is automatically approved. You can enter any integer from zero (0) to 360. For most scenarios, we recommend waiting no more than 100 days.
     + **Approve patches released up to a specific date**: The patch release date for which Patch Manager automatically applies all patches released or updated on or before that date. For example, if you specify July 7, 2023, no patches released or last updated on or after July 8, 2023, are installed automatically.
   + (Optional) **Compliance reporting**: The severity level you want to assign to patches approved by the baseline, such as `Critical` or `High`.
**Note**  
If you specify a compliance reporting level and the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified.

1. (Optional) If you want to explicitly approve any patches instead of letting patches be selected according to approval rules, do the following in the **Patch exceptions** section:
   + For **Approved patches**, enter a comma-separated list of the patches you want to approve.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + (Optional) For **Approved patches compliance level**, assign a compliance level to the patches in the list.

1. If you want to explicitly reject any patches that otherwise meet your approval rules, do the following in the **Patch exceptions** section:
   + For **Rejected patches**, enter a comma-separated list of the patches you want to reject.

     For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md).
   + For **Rejected patches action**, select the action for Patch Manager to take on patches included in the **Rejected patches** list.
     + **Allow as dependency**: Windows Server doesn't support the concept of package dependencies. If a package in the **Rejected patches** list and already installed on the node, its status is reported as `INSTALLED_OTHER`. Any package not already installed on the node is skipped. 
     + **Block**: Packages in the **Rejected patches** list aren't installed by Patch Manager under any circumstances. If a package was installed before it was added to the **Rejected patches** list, or is installed outside of Patch Manager afterward, it's considered noncompliant with the patch baseline and its status is reported as `INSTALLED_REJECTED`.

     For more information about rejected package actions, see [Rejected patch list options in custom patch baselines](patch-manager-windows-and-linux-differences.md#rejected-patches-diff). 

1. (Optional) For **Manage tags**, apply one or more tag key name/value pairs to the patch baseline.

   Tags are optional metadata that you assign to a resource. Tags allow you to categorize a resource in different ways, such as by purpose, owner, or environment. For example, you might want to tag a patch baseline to identify the severity level of patches it specifies, the operating system family it applies to, and the environment type. In this case, you could specify tags similar to the following key name/value pairs:
   + `Key=PatchSeverity,Value=Critical`
   + `Key=OS,Value=RHEL`
   + `Key=Environment,Value=Production`

1. Choose **Create patch baseline**.

# Updating or deleting a custom patch baseline
<a name="patch-manager-update-or-delete-a-patch-baseline"></a>

You can update or delete a custom patch baseline that you have created in Patch Manager, a tool in AWS Systems Manager. When you update a patch baseline, you can change its name or description, its approval rules, and its exceptions for approved and rejected patches. You can also update the tags that are applied to the patch baseline. You can't change the operating system type that a patch baseline has been created for, and you can't make changes to a predefined patch baseline provided by AWS.

## Updating or deleting a patch baseline
<a name="sysman-maintenance-update-mw"></a>

Follow these steps to update or delete a patch baseline.

**Important**  
 Use caution when deleting a custom patch baseline that might be used by a patch policy configuration in Quick Setup.  
If you are using a [patch policy configuration](patch-manager-policies.md) in Quick Setup, updates you make to custom patch baselines are synchronized with Quick Setup once an hour.   
If a custom patch baseline that was referenced in a patch policy is deleted, a banner displays on the Quick Setup **Configuration details** page for your patch policy. The banner informs you that the patch policy references a patch baseline that no longer exists, and that subsequent patching operations will fail. In this case, return to the Quick Setup **Configurations** page, select the Patch Manager configuration , and choose **Actions**, **Edit configuration**. The deleted patch baseline name is highlighted, and you must select a new patch baseline for the affected operating system.

**To update or delete a patch baseline**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the patch baseline that you want to update or delete, and then do one of the following:
   + To remove the patch baseline from your AWS account, choose **Delete**. The system prompts you to confirm your actions. 
   + To make changes to the patch baseline name or description, approval rules, or patch exceptions, choose **Edit**. On the **Edit patch baseline** page, change the values and options that you want, and then choose **Save changes**. 
   + To add, change, or delete tags applied to the patch baseline, choose the **Tags** tab, and then choose **Edit tags**. On the **Edit patch baseline tags** page, make updates to the patch baseline tags, and then choose **Save changes**. 

   For information about the configuration choices you can make, see [Working with custom patch baselines](patch-manager-manage-patch-baselines.md).

# Setting an existing patch baseline as the default
<a name="patch-manager-default-patch-baseline"></a>

**Important**  
Any default patch baseline selections you make here do not apply to patching operations that are based on a patch policy. Patch policies use their own patch baseline specifications. For more information about patch policies, see [Patch policy configurations in Quick Setup](patch-manager-policies.md).

When you create a custom patch baseline in Patch Manager, a tool in AWS Systems Manager, you can set the baseline as the default for the associated operating system type as soon as you create it. For information, see [Working with custom patch baselines](patch-manager-manage-patch-baselines.md).

You can also set an existing patch baseline as the default for an operating system type.

**Note**  
The steps you follow depend on whether you first accessed Patch Manager before or after the patch policies release on December 22, 2022. If you used Patch Manager before that date, you can use the console procedure. Otherwise, use the AWS CLI procedure. The **Actions** menu referenced in the console procedure is not displayed in Regions where Patch Manager wasn't used before the patch policies release.

**To set a patch baseline as the default**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Patch baselines** tab.

1. In the patch baselines list, choose the button of a patch baseline that isn't currently set as the default for an operating system type.

   The **Default baseline** column indicates which baselines are currently set as the defaults.

1. In the **Actions** menu, choose **Set default patch baseline**.
**Important**  
The **Actions** menu is not available if you didn't work with Patch Manager in the current AWS account and Region before December 22, 2022. See the **Note** earlier in this topic for more information.

1. In the confirmation dialog box, choose **Set default**.

**To set a patch baseline as the default (AWS CLI)**

1. Run the [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) command to view a list of available patch baselines and their IDs and Amazon Resource Names (ARNs).

   ```
   aws ssm describe-patch-baselines
   ```

1. Run the [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) command to set a baseline as the default for the operating system it's associated with. Replace *baseline-id-or-ARN* with the ID of the custom patch baseline or predefined baseline to use. 

------
#### [ Linux & macOS ]

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id baseline-id-or-ARN
   ```

   The following is an example of a setting a custom baseline as the default.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   The following is an example of a setting a predefined baseline managed by AWS as the default.

   ```
   aws ssm register-default-patch-baseline \
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
   ```

------
#### [ Windows Server ]

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id baseline-id-or-ARN
   ```

   The following is an example of a setting a custom baseline as the default.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id pb-abc123cf9bEXAMPLE
   ```

   The following is an example of a setting a predefined baseline managed by AWS as the default.

   ```
   aws ssm register-default-patch-baseline ^
       --baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
   ```

------

# Viewing available patches
<a name="patch-manager-view-available-patches"></a>

With Patch Manager, a tool in AWS Systems Manager, you can view all available patches for a specified operating system and, optionally, a specific operating system version.

**Tip**  
To generate a list of available patches and save them to a file, you can use the [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) command and specify your preferred [output](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html).

**To view available patches**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Patches** tab.

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, and then choose the **Patches** tab.
**Note**  
For Windows Server, the **Patches** tab displays updates that are available from Windows Server Update Service (WSUS).

1. For **Operating system**, choose the operating system for which you want to view available patches, such as `Windows` or `Amazon Linux`.

1. (Optional) For **Product**, choose an OS version, such as `WindowsServer2019` or `AmazonLinux2018.03`.

1. (Optional) To add or remove information columns for your results, choose the configure button (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/configure-button.png)) at the top right of the **Patches** list. (By default, the **Patches** tab displays columns for only some of the available patch metadata.)

   For information about the types of metadata you can add to your view, see [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) in the *AWS Systems Manager API Reference*.

# Creating and managing patch groups
<a name="patch-manager-tag-a-patch-group"></a>

If you are *not* using patch policies in your operations, you can organize your patching efforts by adding managed nodes to patch groups by using tags.

**Note**  
Patch groups are not used in patching operations that are based on *patch policies*. For information about working with patch policies, see [Patch policy configurations in Quick Setup](patch-manager-policies.md).  
Patch group functionality is not supported in the console for account-Region pairs that did not already use patch groups before patch policy support was released on December 22, 2022. Patch group functionality is still available in account-Region pairs that began using patch groups before this date.

To use tags in patching operations, you must apply the tag key `Patch Group` or `PatchGroup` to your managed nodes. You must also specify the name that you want to give the patch group as the value of the tag. You can specify any tag value, but the tag key must be `Patch Group` or `PatchGroup`.

`PatchGroup` (without a space) is required if you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS). 

After you group your managed nodes using tags, you add the patch group value to a patch baseline. By registering the patch group with a patch baseline, you ensure that the correct patches are installed during the patching operation. For more information about patch groups, see [Patch groups](patch-manager-patch-groups.md).

Complete the tasks in this topic to prepare your managed nodes for patching using tags with your nodes and patch baseline. Task 1 is required only if you are patching Amazon EC2 instances. Task 2 is required only if you are patching non-EC2 instances in a [hybrid and multicloud](operating-systems-and-machine-types.md#supported-machine-types) environment. Task 3 is required for all managed nodes.

**Tip**  
You can also add tags to managed nodes using the AWS CLI command `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` or the Systems Manager API operation ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`.

**Topics**
+ [Task 1: Add EC2 instances to a patch group using tags](#sysman-patch-group-tagging-ec2)
+ [Task 2: Add managed nodes to a patch group using tags](#sysman-patch-group-tagging-managed)
+ [Task 3: Add a patch group to a patch baseline](#sysman-patch-group-patchbaseline)

## Task 1: Add EC2 instances to a patch group using tags
<a name="sysman-patch-group-tagging-ec2"></a>

You can add tags to EC2 instances using the Systems Manager console or the Amazon EC2 console. This task is required only if you are patching Amazon EC2 instances.

**Important**  
You can't apply the `Patch Group` tag (with a space) to an Amazon EC2 instance if the **Allow tags in instance metadata** option is enabled on the instance. Allowing tags in instance metadata prevents tag key names from containing spaces. If you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), you must use the tag key `PatchGroup` (without a space).

**Option 1: To add EC2 instances to a patch group (Systems Manager console)**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Fleet Manager**.

1. In the **Managed nodes** list, choose the ID of a managed EC2 instance that you want to configure for patching. Node IDs for EC2 instances begin with `i-`.
**Note**  
When using the Amazon EC2 console and AWS CLI, it's possible to apply `Key = Patch Group` or `Key = PatchGroup` tags to instances that aren't yet configured for use with Systems Manager.  
If a managed node you expect to see isn't listed, see [Troubleshooting managed node availability](fleet-manager-troubleshooting-managed-nodes.md) for troubleshooting tips.

1. Choose the **Tags** tab, then choose **Edit**.

1. In the left column, enter **Patch Group** or **PatchGroup**. If you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), you must use `PatchGroup` (without a space).

1. In the right column, enter a tag value to serve as the name for the patch group.

1. Choose **Save**.

1. Repeat this procedure to add other EC2 instances to the same patch group.

**Option 2: To add EC2 instances to a patch group (Amazon EC2 console)**

1. Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2/), and then choose **Instances** in the navigation pane. 

1. In the list of instances, choose an instance that you want to configure for patching.

1. In the **Actions** menu, choose **Instance settings**, **Manage tags**.

1. Choose **Add new tag**.

1. For **Key**, enter **Patch Group** or **PatchGroup**. If you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), you must use `PatchGroup` (without a space).

1. For **Value**, enter a value to serve as the name for the patch group.

1. Choose **Save**.

1. Repeat this procedure to add other instances to the same patch group.

## Task 2: Add managed nodes to a patch group using tags
<a name="sysman-patch-group-tagging-managed"></a>

Follow the steps in this topic to add tags to AWS IoT Greengrass core devices and non-EC2 hybrid-activated managed nodes (mi-\$1). This task is required only if you are patching non-EC2 instances in a hybrid and multicloud environment.

**Note**  
You can't add tags for non-EC2 managed nodes using the Amazon EC2 console.

**To add non-EC2 managed nodes to a patch group (Systems Manager console)**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Fleet Manager**.

1. In the **Managed nodes** list, choose the name of the managed node that you want to configure for patching.
**Note**  
If a managed node you expect to see isn't listed, see [Troubleshooting managed node availability](fleet-manager-troubleshooting-managed-nodes.md) for troubleshooting tips.

1. Choose the **Tags** tab, then choose **Edit**.

1. In the left column, enter **Patch Group** or **PatchGroup**. If you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), you must use `PatchGroup` (without a space).

1. In the right column, enter a tag value to serve as the name for the patch group.

1. Choose **Save**.

1. Repeat this procedure to add other managed nodes to the same patch group.

## Task 3: Add a patch group to a patch baseline
<a name="sysman-patch-group-patchbaseline"></a>

To associate a specific patch baseline with your managed nodes, you must add the patch group value to the patch baseline. By registering the patch group with a patch baseline, you can ensure that the correct patches are installed during a patching operation. This task is required whether you are patching EC2 instances, non-EC2 managed nodes, or both.

For more information about patch groups, see [Patch groups](patch-manager-patch-groups.md).

**Note**  
The steps you follow depend on whether you first accessed Patch Manager before or after the [patch policies](patch-manager-policies.md) release on December 22, 2022.

**To add a patch group to a patch baseline (Systems Manager console)**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. In the navigation pane, choose **Patch Manager**.

1. If you're accessing Patch Manager for the first time in the current AWS Region and the Patch Manager start page opens, choose **Start with an overview**.

1. Choose the **Patch baselines** tab, and then in the **Patch baselines** list, choose the name of the patch baseline that you want to configure for your patch group.

   If you didn't first access Patch Manager until after the patch policies release, you must choose a custom baseline that you have created.

1. If the **Baseline ID** details page includes an **Actions** menu, do the following: 
   + Choose **Actions**, then **Modify patch groups**.
   + Enter the tag *value* you added to your managed nodes in [Task 2: Add managed nodes to a patch group using tags](#sysman-patch-group-tagging-managed), then choose **Add**.

   If the **Baseline ID** details page does *not* include an **Actions** menu, patch groups can't be configured in the console. Instead, you can do either of the following:
   + (Recommended) Set up a patch policy in Quick Setup, a tool in AWS Systems Manager, to map a patch baseline to one or more EC2 instances.

     For more information, see [Using Quick Setup patch policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) and [Automate organization-wide patching using a Quick Setup patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
   + Use the [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html) command in the AWS Command Line Interface (AWS CLI) to configure a patch group.

# Integrating Patch Manager with AWS Security Hub CSPM
<a name="patch-manager-security-hub-integration"></a>

[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) provides you with a comprehensive view of your security state in AWS. Security Hub CSPM collects security data from across AWS accounts, AWS services, and supported third-party partner products. With Security Hub CSPM, you can check your environment against security industry standards and best practices. Security Hub CSPM helps you to analyze your security trends and identify the highest priority security issues.

By using the integration between Patch Manager, a tool in AWS Systems Manager, and Security Hub CSPM, you can send findings about noncompliant nodes from Patch Manager to Security Hub CSPM. A finding is the observable record of a security check or security-related detection. Security Hub CSPM can then include those patch-related findings in its analysis of your security posture.

The information in the following topics applies no matter which method or type of configuration you are using for your patching operations:
+ A patch policy configured in Quick Setup
+ A Host Management option configured in Quick Setup
+ A maintenance window to run a patch `Scan` or `Install` task
+ An on-demand **Patch now** operation

**Contents**
+ [How Patch Manager sends findings to Security Hub CSPM](#securityhub-integration-sending-findings)
  + [Types of findings that Patch Manager sends](#securityhub-integration-finding-types)
  + [Latency for sending findings](#securityhub-integration-finding-latency)
  + [Retrying when Security Hub CSPM isn't available](#securityhub-integration-retry-send)
  + [Viewing findings in Security Hub CSPM](#securityhub-integration-view-findings)
+ [Typical finding from Patch Manager](#securityhub-integration-finding-example)
+ [Turning on and configuring the integration](#securityhub-integration-enable)
+ [How to stop sending findings](#securityhub-integration-disable)

## How Patch Manager sends findings to Security Hub CSPM
<a name="securityhub-integration-sending-findings"></a>

In Security Hub CSPM, security issues are tracked as findings. Some findings come from issues that are detected by other AWS services or by third-party partners. Security Hub CSPM also has a set of rules that it uses to detect security issues and generate findings.

 Patch Manager is one of the Systems Manager tools that sends findings to Security Hub CSPM. After you perform a patching operation by running a SSM document (`AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, or `AWS-RunPatchBaselineWithHooks`), the patching information is sent to Inventory or Compliance, tools in AWS Systems Manager, or both. After Inventory, Compliance, or both receive the data, Patch Manager receives a notification. Then, Patch Manager evaluates the data for accuracy, formatting, and compliance. If all conditions are met, Patch Manager forwards the data to Security Hub CSPM.

Security Hub CSPM provides tools to manage findings from across all of these sources. You can view and filter lists of findings and view details for a finding. For more information, see [Viewing findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) in the *AWS Security Hub User Guide*. You can also track the status of an investigation into a finding. For more information, see [Taking action on findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) in the *AWS Security Hub User Guide*.

All findings in Security Hub CSPM use a standard JSON format called the AWS Security Finding Format (ASFF). The ASFF includes details about the source of the issue, the affected resources, and the current status of the finding. For more information, see [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) in the *AWS Security Hub User Guide*.

### Types of findings that Patch Manager sends
<a name="securityhub-integration-finding-types"></a>

Patch Manager sends the findings to Security Hub CSPM using the [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). In ASFF, the `Types` field provides the finding type. Findings from Patch Manager have the following value for `Types`:
+ Software and Configuration Checks/Patch Management

 Patch Manager sends one finding per noncompliant managed node. The finding is reported with the resource type [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance) so that findings can be correlated with other Security Hub CSPM integrations that report `AwsEc2Instance` resource types. Patch Manager only forwards a finding to Security Hub CSPM if the operation discovered the managed node to be noncompliant. The finding includes the Patch Summary results. 

**Note**  
After reporting a noncompliant node to Security Hub CSPM. Patch Manager doesn't send an update to Security Hub CSPM after the node is made compliant. You can manually resolve findings in Security Hub CSPM after the required patches have been applied to the managed node.

For more information about compliance definitions, see [Patch compliance state values](patch-manager-compliance-states.md). For more information about `PatchSummary`, see [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html) in the *AWS Security Hub API Reference*.

### Latency for sending findings
<a name="securityhub-integration-finding-latency"></a>

When Patch Manager creates a new finding, it's usually sent to Security Hub CSPM within a few seconds to 2 hours. The speed depends on the traffic in the AWS Region being processed at that time.

### Retrying when Security Hub CSPM isn't available
<a name="securityhub-integration-retry-send"></a>

If there is a service outage, an AWS Lambda function is run to put the messages back into the main queue after the service is running again. After the messages are in the main queue, the retry is automatic.

If Security Hub CSPM isn't available, Patch Manager retries sending the findings until they're received.

### Viewing findings in Security Hub CSPM
<a name="securityhub-integration-view-findings"></a>

This procedure describes how to view findings in Security Hub CSPM about managed nodes in your fleet that are out of patch compliance.

**To review Security Hub CSPM findings for patch compliance**

1. Sign in to the AWS Management Console and open the AWS Security Hub CSPM console at [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/).

1. In the navigation pane, choose **Findings**.

1. Choose the **Add filters** (![\[The Search icon\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/search-icon.png)) box.

1. In the menu, under **Filters**, choose **Product name**.

1. In the dialog box that opens, choose **is** in the first field and then enter **Systems Manager Patch Manager** in the second field.

1. Choose **Apply**.

1. Add any additional filters you want to help narrow down your results.

1. In the list of results, choose the title of a finding you want more information about.

   A pane opens on the right side of the screen with more details about the resource, the issue discovered, and a recommended remediation.
**Important**  
At this time, Security Hub CSPM reports the resource type of all managed nodes as `EC2 Instance`. This includes on-premises servers and virtual machines (VMs) that you have registered for use with Systems Manager.

**Severity classifications**  
The list of findings for **Systems Manager Patch Manager** includes a report of the severity of the finding. **Severity** levels include the following, from lowest to highest:
+ **INFORMATIONAL ** – No issue was found.
+ **LOW** – The issue does not require remediation.
+ **MEDIUM** – The issue must be addressed but is not urgent.
+ **HIGH** – The issue must be addressed as a priority.
+ **CRITICAL** – The issue must be remediated immediately to avoid escalation.

Severity is determined by the most severe noncompliant package on an instance. Because you can have multiple patch baselines with multiple severity levels, the highest severity is reported out of all the noncompliant packages. For example, suppose you have two noncompliant packages where the severity of package A is "Critical" and the severity of package B is "Low". "Critical" will be reported as the severity.

Note that the severity field correlates directly with the Patch Manager `Compliance` field. This is a field that you set assign to individual patches that match the rule. Because this `Compliance` field is assigned to individual patches, it is not reflected at the Patch Summary level.

**Related content**
+ [Findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) in the *AWS Security Hub User Guide*
+ [Multi-Account patch compliance with Patch Manager and Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) in the *AWS Management & Governance Blog*

## Typical finding from Patch Manager
<a name="securityhub-integration-finding-example"></a>

Patch Manager sends findings to Security Hub CSPM using the [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).

Here is an example of a typical finding from Patch Manager.

```
{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
  "GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
  "AwsAccountId": "111122223333",
  "Types": [
    "Software & Configuration Checks/Patch Management/Compliance"
  ],
  "CreatedAt": "2021-11-11T22:05:25Z",
  "UpdatedAt": "2021-11-11T22:05:25Z",
  "Severity": {
    "Label": "INFORMATIONAL",
    "Normalized": 0
  },
  "Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
  "Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
  "Remediation": {
    "Recommendation": {
      "Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
      "Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
    }
  },
  "SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
  "ProductFields": {
    "aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
    "aws/securityhub/ProductName": "Systems Manager Patch Manager",
    "aws/securityhub/CompanyName": "AWS"
  },
  "Resources": [
    {
      "Type": "AwsEc2Instance",
      "Id": "i-02573cafcfEXAMPLE",
      "Partition": "aws",
      "Region": "us-east-2"
    }
  ],
  "WorkflowState": "NEW",
  "Workflow": {
    "Status": "NEW"
  },
  "RecordState": "ACTIVE",
  "PatchSummary": {
    "Id": "pb-0c10e65780EXAMPLE",
    "InstalledCount": 45,
    "MissingCount": 2,
    "FailedCount": 0,
    "InstalledOtherCount": 396,
    "InstalledRejectedCount": 0,
    "InstalledPendingReboot": 0,
    "OperationStartTime": "2021-11-11T22:05:06Z",
    "OperationEndTime": "2021-11-11T22:05:25Z",
    "RebootOption": "NoReboot",
    "Operation": "SCAN"
  }
}
```

## Turning on and configuring the integration
<a name="securityhub-integration-enable"></a>

To use the Patch Manager integration with Security Hub CSPM, you must turn on Security Hub CSPM. For information about how to turn on Security Hub CSPM, see [Setting up Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) in the *AWS Security Hub User Guide*.

The following procedure describes how to integrate Patch Manager and Security Hub CSPM when Security Hub CSPM is already active but Patch Manager integration is turned off. You only need to complete this procedure if integration was manually turned off.

**To add Patch Manager to Security Hub CSPM integration**

1. In the navigation pane, choose **Patch Manager**.

1. Choose the **Settings** tab.

   -or-

   If you are accessing Patch Manager for the first time in the current AWS Region, choose **Start with an overview**, and then choose the **Settings** tab.

1. Under the **Export to Security Hub CSPM** section, to the right of **Patch compliance findings aren't being exported to Security Hub**, choose **Enable**.

## How to stop sending findings
<a name="securityhub-integration-disable"></a>

To stop sending findings to Security Hub CSPM, you can use either the Security Hub CSPM console or the API.

For more information, see the following topics in the *AWS Security Hub User Guide*:
+ [Disabling and enabling the flow of findings from an integration (console)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Disabling the flow of findings from an integration (Security Hub CSPM API, AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)