Repo sync

content/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/viewing-and-managing-a-users-saml-access-to-your-enterprise.md

@@ -78,7 +78,7 @@ The identity data on this page will include the SCIM data that was sent to {% da
 
 {% ifversion single_user_cred_revocation %}
 
-You can also revoke SSO authorizations for individual users or all users. For enterprises with {% data variables.product.prodname_emus %}, you can delete credentials entirely. This is useful for responding to security incidents. For more information, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens).
+> [!TIP] To respond to security incidents, enterprise and organization owners can also revoke all SSO authorizations at once for individual users, all users, or a specific credential type such as {% data variables.product.pat_v1_plural %}. For enterprises with {% data variables.product.prodname_emus %}, you can delete credentials entirely. For more information, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens).
 
 {% endif %}
 

content/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens.md

@@ -23,7 +23,12 @@ Available actions:
 In the "Authentication security" section of your enterprise settings, you can review counts for user tokens and keys that are authorized for single sign-on (SSO). Then, if needed, you can take action against credentials:
 
 * **For individual members**: Revoke SSO authorizations or delete credentials for a specific user when responding to a targeted incident or performing routine access cleanup.
-* **For all members (bulk action)**: Take bulk action to revoke SSO authorizations or delete credentials across all members when responding to a major security incident.
+* **For a specific credential type**: Revoke SSO authorizations or delete credentials of a selected type, such as only {% data variables.product.pat_v1_plural %}, across your entire enterprise.
+* **For all members (bulk action)**: Take bulk action to revoke SSO authorizations or delete credentials across all members and every supported credential type, such as when responding to a major security incident.
+
+You can also take any of these actions using the [AUTOTITLE](/rest/enterprise-admin/credential-authorizations).
+
+> [!NOTE] Organization owners can take the same actions at the organization level, using the {% data variables.product.github %} UI or the [AUTOTITLE](/rest/orgs/orgs#revoke-a-single-credential-type-for-an-organization). For more information, see [AUTOTITLE](/organizations/granting-access-to-your-organization-with-saml-single-sign-on/viewing-and-managing-a-members-saml-access-to-your-organization).
 
 {% else %}
 
@@ -56,11 +61,15 @@ The following sections describe what each action does, which SSO authorizations
 
 > [!NOTE] If your enterprise does **not** use {% data variables.product.prodname_emus %} and has **not** enabled SAML SSO, neither of these actions is available. As an alternative, if you need users to replace {% data variables.product.pat_generic_plural %} as part of your incident response, you can configure an enterprise policy to expire all {% data variables.product.pat_generic_plural %}. See [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-personal-access-tokens-in-your-enterprise).
 
+{% ifversion single_user_cred_revocation %}
+By default, each action targets all credential types that support it. You can instead scope an action to a single credential type, such as {% data variables.product.pat_v1_plural %} or user SSH keys, to contain an incident without disrupting other credentials. See [Included credentials](#included-credentials) for the credential types that support each action.
+{% endif %}
+
 ### Revoke SSO authorizations
 
 This action is available for {% data variables.product.prodname_emus %} or enterprises that use SAML SSO.
 
-Revoking authorizations removes SSO authorizations for user tokens and SSH keys{% ifversion single_user_cred_revocation %}, either for a specific user or{% endif %} across all organizations in your enterprise.
+Revoking authorizations removes SSO authorizations for user tokens and SSH keys{% ifversion single_user_cred_revocation %}, either for a specific user, all users, or a specific credential type,{% endif %} across all organizations in your enterprise.
 
 * Credentials that have had SSO authorizations revoked **cannot be re-authorized** for the affected organizations. To restore access, users must create new credentials and authorize them.
 * The credentials themselves are not deleted, and their permissions for the user and enterprise scopes, and for non-SSO-protected organizations, **remain active**.
@@ -72,9 +81,9 @@ Authorization for **{% data variables.product.pat_v2_plural %}** works different
 
 This action is available for {% data variables.product.prodname_emus %} only.
 
-Deleting keys and tokens removes credentials that have access to your enterprise{% ifversion single_user_cred_revocation %}, either for a specific user or for all users{% endif %}, regardless of whether they are authorized for SSO. The credentials stop working and are no longer visible in the UI.
+Deleting keys and tokens removes credentials that have access to your enterprise{% ifversion single_user_cred_revocation %}, either for a specific user, all users, or a specific credential type{% endif %}, regardless of whether they are authorized for SSO. The credentials stop working and are no longer visible in the UI.
 
-To restore programmatic access, users must create new credentials, authorize them with organizations if required, and update affected processes to use the new credentials.
+{% ifversion single_user_cred_revocation %}For example, you can delete all {% data variables.product.pat_generic_plural %} for an individual member without affecting that member's SSH keys.{% endif %} To restore programmatic access, users must create new credentials, authorize them with organizations if required, and update affected processes to use the new credentials.
 
 ### Included credentials
 
@@ -99,7 +108,7 @@ The following credential types are **not** affected:
 
 ### Audit and security log events
 
-The "revoke authorizations" action generates the following events:
+The "revoke authorizations" action generates the following events, whether it's scoped to a specific user, a specific credential type, or all members:
 
 * `org_credential_authorization.deauthorize`
 * `org_credential_authorization.revoke`
@@ -110,6 +119,8 @@ The "delete tokens" action also generates those events, and additionally generat
 * `oauth_access.destroy`
 * `personal_access_token.destroy`
 
+Affected users receive an email notification when their SSO authorizations are revoked or their credentials are deleted, whether the action was initiated by an enterprise owner or by the user themselves.
+
 {% ifversion single_user_cred_revocation %}
 
 ## Taking action against individual members
@@ -138,6 +149,34 @@ This action is available for {% data variables.product.prodname_emus %} only.
 1. To confirm, type `USERNAME credentials` (replacing `USERNAME` with the user's username).
 1. Click **Delete keys and tokens**.
 
+## Taking action against a specific credential type
+
+You can revoke SSO authorizations or delete credentials of a single type across your entire enterprise, without affecting other credential types. For example, you can revoke SSO authorizations for all {% data variables.product.pat_v1_plural %} while leaving user SSH keys and other credential types untouched.
+
+### Revoking authorizations for a credential type
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.settings-tab %}
+1. In the left sidebar, click **Authentication security**.
+1. In the "Danger zone" section, click **Revoke for ▼**, then click the credential type whose authorizations you want to revoke.
+1. Read the warning about the impact of this action.
+1. To confirm, type the name of your enterprise.
+1. Click **Revoke authorizations**.
+
+### Deleting credentials of a specific type
+
+This action is available for {% data variables.product.prodname_emus %} only.
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.settings-tab %}
+1. In the left sidebar, click **Authentication security**.
+1. In the "Danger zone" section, click **Delete for ▼**, then click the credential type whose credentials you want to delete.
+1. Read the warning about the impact of this action.
+1. To confirm, type the name of your enterprise.
+1. Click **Delete keys and tokens**.
+
+You can also combine these actions with a specific user, by selecting a user first and then choosing a credential type, or perform either action using the [AUTOTITLE](/rest/enterprise-admin/credential-authorizations).
+
 {% endif %}
 
 ## Taking bulk action against all members
@@ -175,3 +214,4 @@ The following articles describe alternative actions for managing incidents that
 * [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/identifying-audit-log-events-performed-by-an-access-token)
 * [AUTOTITLE](/code-security/tutorials/remediate-leaked-secrets/remediating-a-leaked-secret)
 * [AUTOTITLE](/rest/credentials/revoke) in the REST API documentation
+* [AUTOTITLE](/rest/orgs/orgs#revoke-a-single-credential-type-for-an-organization) in the REST API documentation

content/authentication/keeping-your-account-and-data-secure/revoking-your-credentials.md

@@ -17,6 +17,8 @@ Depending on your account type, the following actions are available:
 
 > [!WARNING] These actions are irreversible. Once you revoke authorizations or delete credentials, you cannot restore them. You will need to create new credentials and re-authorize them for any organizations or processes that require access.
 
+These actions are recorded in the audit log for any enterprise you belong to, and you will receive an email notification confirming the action.
+
 ## Understanding the impact
 
 Before taking action, consider the following:
@@ -58,3 +60,4 @@ After taking action on your credentials:
 * [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)
 * [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys)
 * [AUTOTITLE](/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps)
+* [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)

content/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation.md

@@ -88,7 +88,7 @@ User access tokens created by a {% data variables.product.prodname_github_app %}
 
 ## Token revoked by enterprise owners
 
-Enterprise owners on {% data variables.product.prodname_ghe_cloud %} can revoke SSO authorizations or delete credentials{% ifversion single_user_cred_revocation %} for individual users or{% endif %} in bulk when responding to security incidents. Revoking SSO authorizations removes access to SSO-protected organization resources, while deleting credentials (available for {% data variables.product.prodname_emus %} only) removes the credentials entirely.
+Enterprise owners on {% data variables.product.prodname_ghe_cloud %} can revoke SSO authorizations or delete credentials{% ifversion single_user_cred_revocation %} for individual users, for a specific credential type, or{% endif %} in bulk when responding to security incidents. Revoking SSO authorizations removes access to SSO-protected organization resources, while deleting credentials (available for {% data variables.product.prodname_emus %} only) removes the credentials entirely.{% ifversion single_user_cred_revocation %} Organization owners can take the same actions at the organization level. These actions are recorded in the audit log, and you will receive an email notification.{% endif %}
 
 For more information, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens).
 

content/code-security/tutorials/secure-your-organization/respond-to-a-security-incident.md

@@ -122,12 +122,20 @@ For exposed or exploited credentials, the most immediate action you can take is
 {% ifversion single_user_cred_revocation %}
 * **Revoke or delete credentials for a specific user**
 
-  If you've identified a specific compromised account, enterprise owners on {% data variables.product.prodname_ghe_cloud %} can revoke SSO authorizations for that individual user. For enterprises with {% data variables.product.prodname_emus %}, you can also delete credentials entirely. This is less disruptive than bulk actions while still containing the threat. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-individual-members).
+  If you've identified a specific compromised account, enterprise or organization owners on {% data variables.product.prodname_ghe_cloud %} can revoke SSO authorizations for that individual user. For enterprises with {% data variables.product.prodname_emus %}, you can also delete credentials entirely. This is less disruptive than bulk actions while still containing the threat. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-individual-members).
+
+* **Revoke or delete credentials of a specific type**
+
+  If the incident is limited to one credential type, such as {% data variables.product.pat_v1_plural %}, enterprise or organization owners can revoke SSO authorizations or delete credentials of that type only, across all members, using the {% data variables.product.github %} UI{% ifversion ghec %} or REST API{% endif %}. This targets the affected credential type without disrupting other credentials. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens#taking-action-against-a-specific-credential-type).
 
 {% endif %}
 * **Emergency actions (major incident)**
 
-  Enterprise owners on {% data variables.product.prodname_ghe_cloud %} can take bulk emergency actions to lock down access across their enterprise. For enterprises with {% data variables.product.prodname_emus %}, this includes **deleting all user tokens and keys**. These are high-impact actions that will break automations and should be reserved for major incidents. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents).
+  Enterprise{% ifversion single_user_cred_revocation %} and organization{% endif %} owners on {% data variables.product.prodname_ghe_cloud %} can take bulk emergency actions to lock down access across their enterprise{% ifversion single_user_cred_revocation %} or organization{% endif %}. For enterprises with {% data variables.product.prodname_emus %}, this includes **deleting all user tokens and keys**. These are high-impact actions that will break automations and should be reserved for major incidents. See [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents).
+
+{% ifversion single_user_cred_revocation %}
+All of these de-authorization and revocation actions, whether initiated by an admin or by the affected user, are recorded in the audit log, and the affected user receives an email notification.
+{% endif %}
 
 ### Restrict access
 

content/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs.md

@@ -46,6 +46,9 @@ You can also filter by a specific event. For example, `action:copilot.cfb_seat_a
 
 To view a record of agent activity, use the `actor:Copilot` search term. See [AUTOTITLE](/copilot/reference/enterprise-administrators/agentic-audit-log-events).
 
+> [!NOTE]
+> For team-based seat assignments, the `copilot.cfb_seat_added` event's actor may not be the account that performed the membership change. See [AUTOTITLE](/copilot/reference/copilot-billing/seat-assignment#seat-assignment-management).
+
 ## Retaining audit log history
 
 The audit log retains events for the last 180 days. We recommend streaming the audit log to a Security Information and Event Management (SIEM) platform, where you can view long-term history and set up alerts for anomalous activity. See [AUTOTITLE](/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise).

content/copilot/how-tos/administer-copilot/manage-for-organization/manage-access/grant-access.md

@@ -42,7 +42,9 @@ Billing for {% data variables.product.prodname_copilot %} starts when you grant
 
 {% ifversion ghec %}
 
-> [!NOTE] You can automatically enable access for every member of a group in your identity provider (IdP) by synchronizing that group with a {% data variables.product.prodname_dotcom %} team, then giving that team access to {% data variables.product.prodname_copilot %}. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group).
+You can automatically enable access for every member of a group in your identity provider (IdP) by synchronizing that group with a {% data variables.product.prodname_dotcom %} team, then giving that team access to {% data variables.product.prodname_copilot %}. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group).
+
+When access is granted this way, the `copilot.cfb_seat_added` audit log event attributes the action to whoever originally granted {% data variables.product.prodname_copilot_short %} access to the team, not the account or sync process that added the new team member. See [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization).
 
 {% endif %}
 

content/copilot/reference/copilot-billing/seat-assignment.md

@@ -25,3 +25,4 @@ Users must be assigned a seat to access {% data variables.product.prodname_copil
 * **If a user with an active {% data variables.copilot.copilot_pro_short %}, {% data variables.copilot.copilot_pro_plus_short %}, or {% data variables.copilot.copilot_max_short %} plan is assigned a seat in a {% data variables.copilot.copilot_business_short %} or {% data variables.copilot.copilot_enterprise_short %} plan**, their personal plan is automatically canceled, and a prorated refund for any remaining portion of their personal billing cycle is issued. The user will now use {% data variables.product.prodname_copilot_short %} under the organization's policies.
 * **If a single user receives a seat from multiple organizations within the same enterprise**, the enterprise is only billed once per billing cycle for that unique user. One organization that assigned {% data variables.product.prodname_copilot_short %} to the user is chosen at random each month to be billed for the seat.
 * **If a user is assigned both a  {% data variables.copilot.copilot_business_short %} and a {% data variables.copilot.copilot_enterprise_short %} seat from different organizations within the same enterprise**, only the {% data variables.copilot.copilot_enterprise_short %} seat is billed. The charge is at the {% data variables.copilot.copilot_enterprise_short %} rate from the time the {% data variables.copilot.copilot_enterprise_short %} seat is assigned. The user will have access to the all the features and capabilities available under the {% data variables.copilot.copilot_enterprise_short %} plan.
+* **If a user receives a seat automatically because they were added to a team with {% data variables.product.prodname_copilot_short %} access** (for example, via SCIM or team synchronization), the `copilot.cfb_seat_added` audit log event attributes the action to whoever originally granted {% data variables.product.prodname_copilot_short %} access to that team, not the account that added the new team member. The membership change itself is attributed correctly to the actual actor on the corresponding `team.add_member` or `org.add_member` event. See [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs).