diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller.md
index 6c8d322eb87d..e8d484df47f3 100644
--- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller.md
+++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller.md
@@ -826,8 +826,10 @@ The [Dependabot Action](https://github.com/github/dependabot-action) is used to
 
 Because there is no support for upgrading or deleting CRDs with Helm, it is not possible to use Helm to upgrade ARC. For more information, see [Custom Resource Definitions](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#some-caveats-and-explanations) in the Helm documentation. To upgrade ARC to a newer version, you must complete the following steps.
 
-1. Uninstall ARC.
+1. Uninstall all installations of `gha-runner-scale-set`.
 1. Wait for resources cleanup.
+1. Uninstall ARC.
+1. If there is a change in CRDs from the version you currently have installed, to the upgraded version, remove all CRDs associated with `actions.github.com` API group.
 1. Reinstall ARC again.
 
 For more information, see "[Deploying a runner scale set](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller#deploying-a-runner-scale-set)."
diff --git a/content/actions/using-workflows/events-that-trigger-workflows.md b/content/actions/using-workflows/events-that-trigger-workflows.md
index 9ac7a5e788f0..3eadb51ec71f 100644
--- a/content/actions/using-workflows/events-that-trigger-workflows.md
+++ b/content/actions/using-workflows/events-that-trigger-workflows.md
@@ -184,8 +184,6 @@ on:
   deployment_status
 ```
 
-{% ifversion discussions %}
-
 ## `discussion`
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
@@ -238,8 +236,6 @@ on:
     types: [created, deleted]
 ```
 
-{% endif %}
-
 ## `fork`
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
@@ -1174,7 +1170,7 @@ jobs:
 
 - {% data reusables.actions.schedule-delay %}
 - In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. For information on re-enabling a disabled workflow, see "[AUTOTITLE](/enterprise-server@3.12/actions/using-workflows/disabling-and-enabling-a-workflow#enabling-a-workflow)."
-- When the last user to commit to a scheduled workflow is removed from the organization, the scheduled workflow will be disabled. If a user with `write` permissions to the repository commits to the scheduled workflow file, the scheduled workflow will be re-activated.
+- When the last user to commit to the cron schedule of a workflow is removed from the organization, the scheduled workflow will be disabled. If a user with `write` permissions to the repository makes a commit that changes the cron schedule, the scheduled workflow will be re-activated.
 
 {% endnote %}
 
@@ -1304,11 +1300,11 @@ on: workflow_dispatch
 
 ### Providing inputs
 
-You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When you trigger the event, you can provide the `ref` and any `inputs`. When the workflow runs, you can access the input values in the {% ifversion actions-unified-inputs %}`inputs`{% else %}`github.event.inputs`{% endif %} context. For more information, see "[AUTOTITLE](/actions/learn-github-actions/contexts)."
+You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When you trigger the event, you can provide the `ref` and any `inputs`. When the workflow runs, you can access the input values in the `inputs` context. For more information, see "[AUTOTITLE](/actions/learn-github-actions/contexts)."
 
 {% data reusables.actions.inputs-vs-github-event-inputs %}
 
-This example defines inputs called `logLevel`, `tags`, and `environment`. You pass values for these inputs to the workflow when you run it. This workflow then prints the values to the log, using the {% ifversion actions-unified-inputs %}`inputs.logLevel`, `inputs.tags`, and  `inputs.environment`{% else %}`github.event.inputs.logLevel`, `github.event.inputs.tags`, and  `github.event.inputs.environment`{% endif %} context properties.
+This example defines inputs called `logLevel`, `tags`, and `environment`. You pass values for these inputs to the workflow when you run it. This workflow then prints the values to the log, using the `inputs.logLevel`, `inputs.tags`, and  `inputs.environment` context properties.
 
 ```yaml
 on:
@@ -1341,9 +1337,9 @@ jobs:
           echo "Tags: $TAGS"
           echo "Environment: $ENVIRONMENT"
         env:
-          LEVEL: {% ifversion actions-unified-inputs %}{% raw %}${{ inputs.logLevel }}{% endraw %}{% else %}{% raw %}${{ github.event.inputs.logLevel }}{% endraw %}{% endif %}
-          TAGS: {% ifversion actions-unified-inputs %}{% raw %}${{ inputs.tags }}{% endraw %}{% else %}{% raw %}${{ github.event.inputs.tags }}{% endraw %}{% endif %}
-          ENVIRONMENT: {% ifversion actions-unified-inputs %}{% raw %}${{ inputs.environment }}{% endraw %}{% else %}{% raw %}${{ github.event.inputs.environment }}{% endraw %}{% endif %}
+          LEVEL: {% raw %}${{ inputs.logLevel }}{% endraw %}
+          TAGS: {% raw %}${{ inputs.tags }}{% endraw %}
+          ENVIRONMENT: {% raw %}${{ inputs.environment }}{% endraw %}
 ```
 
 If you run this workflow from a browser you must enter values for the required inputs manually before the workflow will run.
@@ -1362,7 +1358,7 @@ For more information, see the {% data variables.product.prodname_cli %} informat
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|
-| [`workflow_run`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`<br/>- `requested`{% ifversion actions-workflow-run-in-progress %}<br/>- `in_progress`{% endif %} | Last commit on default branch | Default branch |
+| [`workflow_run`](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_run) | - `completed`<br/>- `requested`<br/>- `in_progress` | Last commit on default branch | Default branch |
 
 {% note %}
 
diff --git a/content/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise.md b/content/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise.md
index 9d05fecd9a79..2b4690ed7de0 100644
--- a/content/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise.md
+++ b/content/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise.md
@@ -95,6 +95,20 @@ Deleting a CA cannot be undone. If you want to use the same CA in the future, yo
 {% data reusables.enterprise-accounts.settings-tab %}
 {% data reusables.enterprise-accounts.security-tab %}
 {% data reusables.organizations.delete-ssh-ca %}
+{% ifversion ssh-ca-expires %}
+
+## Upgrading an SSH certificate authority
+
+CAs uploaded to your enterprise {% ifversion ghec %}prior to March 27th, 2024,{% elsif ghes %}before {% data variables.product.prodname_ghe_server %} version 3.13{% endif %} allow the use of non-expiring certificates. To learn more about why expirations are now required for new CAs, see "[AUTOTITLE](/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities#issuing-certificates)." You can upgrade an existing CA to prevent it from issuing non-expiring certificates. For best security, we strongly recommend upgrading all your CAs once you validate you're not reliant on non-expiring certificates.
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.settings-tab %}
+{% data reusables.enterprise-accounts.security-tab %}
+1. Under "SSH Certificate Authorities", to the right of the CA you want to upgrade, click **Upgrade**.
+1. Read the warning, then click **Upgrade**.
+
+After upgrading the CA, non-expiring certificates signed by that CA will be rejected.
+{% endif %}
 
 {% ifversion sso-redirect %}
 
diff --git a/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md b/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
index 253f6a1a6985..06f4aabda473 100644
--- a/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
+++ b/content/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities.md
@@ -41,7 +41,7 @@ If your organization doesn't require SSH certificates, members can continue to u
 
 ## Issuing certificates
 
-When you issue each certificate, you must include an extension that specifies which {% data variables.product.product_name %} user the certificate is for. For example, you can use OpenSSH's `ssh-keygen` command, replacing KEY-IDENTITY with your key identity and USERNAME with a {% data variables.product.product_name %} username. The certificate you generate will be authorized to act on behalf of that user for any of your organization's resources. Make sure you validate the user's identity before you issue the certificate.
+When you issue each certificate, you must include an extension that specifies which {% data variables.product.product_name %} user the certificate is for. You can reference the user using their login handle{% ifversion ssh-ca-expires %} or their user ID{% endif %}. For example, you can use OpenSSH's `ssh-keygen` command, replacing KEY-IDENTITY with your key identity and USERNAME with a {% data variables.product.product_name %} username{% ifversion ssh-ca-expires %} or user ID{% endif %}. The certificate you generate will be authorized to act on behalf of that user for any of your organization's resources. Make sure you validate the user's identity before you issue the certificate.
 
 {% note %}
 
@@ -49,16 +49,34 @@ When you issue each certificate, you must include an extension that specifies wh
 
 {% endnote %}
 
+To use the `login` to identify the user, use `extension:login`:
+
 ```shell
 ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data variables.product.product_url %}=USERNAME ./user-key.pub
 ```
 
+{% ifversion ssh-ca-expires %}
+To use the user ID, use `extension:id`:
+
+```shell
+ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:id@{% data variables.product.product_url %}=ID ./user-key.pub
+```
+
+{% endif %}
 {% warning %}
 
-**Warning**: After a certificate has been signed and issued, the certificate cannot be revoked. Make sure to use the -`V` flag to configure a lifetime for the certificate, or the certificate can be used indefinitely.
+**Warning**: After a certificate has been signed and issued, the certificate cannot be revoked.
 
 {% endwarning %}
 
+For CAs uploaded {% ifversion ghec %}after March 27th, 2024{% elsif ghes %}to {% data variables.product.prodname_ghe_server %} version 3.13 or later{% endif %}, you {% ifversion ghes < 3.13 %}will need to{% else %}must{% endif %} use the `-V` flag to configure a lifetime less than 366 days for the certificate. For CAs uploaded {% ifversion ghec %}before this date{% elsif ghes %}before version 3.13{% endif %}, the `-V` flag is optional, and you can create certificates that are irrevocable and live forever.
+
+{% ifversion ssh-ca-expires %}
+If you have legacy CAs that are exempt from the expiration requirement, you can upgrade the CA to enforce the requirement. To learn more, see "[AUTOTITLE](/organizations/managing-git-access-to-your-organizations-repositories/managing-your-organizations-ssh-certificate-authorities)" and "[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise#managing-ssh-certificate-authorities-for-your-enterprise)."
+
+If you use a username as the login extension, {% data variables.product.company_short %} validates that the named user has not been renamed since the certificate was issued. This prevents a rename attack, where a certificate issued for a username is valid even if the underlying user account changes. To enforce this, the certificate must include the `valid_after` claim, which tells us when the certificate was issued. This field is often missing if an expiration is not required for the certificate, which is why expirations are now required.
+{% endif %}
+
 To issue a certificate for someone who uses SSH to access multiple {% data variables.product.company_short %} products, you can include two login extensions to specify the username for each product. For example, the following command would issue a certificate for USERNAME-1 for the user's account for {% data variables.product.prodname_ghe_cloud %}, and USERNAME-2 for the user's account on {% data variables.product.prodname_ghe_server %} at HOSTNAME.
 
 ```shell
diff --git a/content/organizations/managing-git-access-to-your-organizations-repositories/managing-your-organizations-ssh-certificate-authorities.md b/content/organizations/managing-git-access-to-your-organizations-repositories/managing-your-organizations-ssh-certificate-authorities.md
index 135bdecb6584..9553dabb0290 100644
--- a/content/organizations/managing-git-access-to-your-organizations-repositories/managing-your-organizations-ssh-certificate-authorities.md
+++ b/content/organizations/managing-git-access-to-your-organizations-repositories/managing-your-organizations-ssh-certificate-authorities.md
@@ -38,3 +38,17 @@ If you require SSH certificates for your enterprise, enterprise members should u
 {% data reusables.profile.org_settings %}
 {% data reusables.organizations.security %}
 {% data reusables.organizations.delete-ssh-ca %}
+{% ifversion ssh-ca-expires %}
+
+## Upgrading an SSH certificate authority
+
+CAs uploaded to your organization {% ifversion ghec %}prior to March 27th, 2024,{% elsif ghes %}before {% data variables.product.prodname_ghe_server %} version 3.13{% endif %} allow the use of non-expiring certificates. To learn more about why expirations are now required for new CAs, see "[AUTOTITLE](/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities#issuing-certificates)." You can upgrade an existing CA to prevent it from issuing non-expiring certificates. For best security, we strongly recommend upgrading all your CAs once you validate you're not reliant on non-expiring certificates.
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.security %}
+1. Under "SSH Certificate Authorities", to the right of the CA you want to upgrade, click **Upgrade**.
+1. Read the warning, then click **Upgrade**.
+
+After upgrading the CA, non-expiring certificates signed by that CA will be rejected.
+{% endif %}
diff --git a/data/features/ssh-ca-expires.yml b/data/features/ssh-ca-expires.yml
new file mode 100644
index 000000000000..07c5eea673f5
--- /dev/null
+++ b/data/features/ssh-ca-expires.yml
@@ -0,0 +1,5 @@
+# Reference: #49724
+
+versions:
+  ghec: '*'
+  ghes: '>=3.13'
diff --git a/data/reusables/enterprise/certificate-authority-usage.md b/data/reusables/enterprise/certificate-authority-usage.md
index 312c87b7e570..f131fb21af81 100644
--- a/data/reusables/enterprise/certificate-authority-usage.md
+++ b/data/reusables/enterprise/certificate-authority-usage.md
@@ -1,3 +1,3 @@
-Each certificate authority can only be uploaded to one account on {% data variables.product.prodname_dotcom_the_website %}. If an SSH certificate authority has been added to an organization or enterprise account, you cannot add the same certificate authority to another organization or enterprise account on {% data variables.product.prodname_dotcom_the_website %}.
+Each certificate authority can only be uploaded to one account on {% data variables.product.product_name %}. If an SSH certificate authority has been added to an organization or enterprise account, you cannot add the same certificate authority to another organization or enterprise account on {% data variables.product.product_name %}.
 
 If you add one certificate authority to an enterprise and another certificate authority to an organization in the enterprise, either certificate authority can be used to access the organization's repositories.