Skip to content

Commit 837bf97

Browse files
authored
Merge pull request #45546 from github/repo-sync
Repo sync
2 parents f96c530 + 549e5c6 commit 837bf97

18 files changed

Lines changed: 429 additions & 295 deletions

File tree

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -78,7 +78,7 @@ The identity data on this page will include the SCIM data that was sent to {% da
7878

7979
{% ifversion single_user_cred_revocation %}
8080

81-
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).
81+
> [!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).
8282
8383
{% endif %}
8484

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

Lines changed: 45 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,12 @@ Available actions:
2323
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:
2424

2525
* **For individual members**: Revoke SSO authorizations or delete credentials for a specific user when responding to a targeted incident or performing routine access cleanup.
26-
* **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.
26+
* **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.
27+
* **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.
28+
29+
You can also take any of these actions using the [AUTOTITLE](/rest/enterprise-admin/credential-authorizations).
30+
31+
> [!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).
2732
2833
{% else %}
2934

@@ -56,11 +61,15 @@ The following sections describe what each action does, which SSO authorizations
5661

5762
> [!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).
5863
64+
{% ifversion single_user_cred_revocation %}
65+
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.
66+
{% endif %}
67+
5968
### Revoke SSO authorizations
6069

6170
This action is available for {% data variables.product.prodname_emus %} or enterprises that use SAML SSO.
6271

63-
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.
72+
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.
6473

6574
* 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.
6675
* 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
7281

7382
This action is available for {% data variables.product.prodname_emus %} only.
7483

75-
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.
84+
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.
7685

77-
To restore programmatic access, users must create new credentials, authorize them with organizations if required, and update affected processes to use the new credentials.
86+
{% 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.
7887

7988
### Included credentials
8089

@@ -99,7 +108,7 @@ The following credential types are **not** affected:
99108
100109
### Audit and security log events
101110

102-
The "revoke authorizations" action generates the following events:
111+
The "revoke authorizations" action generates the following events, whether it's scoped to a specific user, a specific credential type, or all members:
103112

104113
* `org_credential_authorization.deauthorize`
105114
* `org_credential_authorization.revoke`
@@ -110,6 +119,8 @@ The "delete tokens" action also generates those events, and additionally generat
110119
* `oauth_access.destroy`
111120
* `personal_access_token.destroy`
112121

122+
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.
123+
113124
{% ifversion single_user_cred_revocation %}
114125

115126
## Taking action against individual members
@@ -138,6 +149,34 @@ This action is available for {% data variables.product.prodname_emus %} only.
138149
1. To confirm, type `USERNAME credentials` (replacing `USERNAME` with the user's username).
139150
1. Click **Delete keys and tokens**.
140151

152+
## Taking action against a specific credential type
153+
154+
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.
155+
156+
### Revoking authorizations for a credential type
157+
158+
{% data reusables.enterprise-accounts.access-enterprise %}
159+
{% data reusables.enterprise-accounts.settings-tab %}
160+
1. In the left sidebar, click **Authentication security**.
161+
1. In the "Danger zone" section, click **Revoke for ▼**, then click the credential type whose authorizations you want to revoke.
162+
1. Read the warning about the impact of this action.
163+
1. To confirm, type the name of your enterprise.
164+
1. Click **Revoke authorizations**.
165+
166+
### Deleting credentials of a specific type
167+
168+
This action is available for {% data variables.product.prodname_emus %} only.
169+
170+
{% data reusables.enterprise-accounts.access-enterprise %}
171+
{% data reusables.enterprise-accounts.settings-tab %}
172+
1. In the left sidebar, click **Authentication security**.
173+
1. In the "Danger zone" section, click **Delete for ▼**, then click the credential type whose credentials you want to delete.
174+
1. Read the warning about the impact of this action.
175+
1. To confirm, type the name of your enterprise.
176+
1. Click **Delete keys and tokens**.
177+
178+
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).
179+
141180
{% endif %}
142181

143182
## Taking bulk action against all members
@@ -175,3 +214,4 @@ The following articles describe alternative actions for managing incidents that
175214
* [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/identifying-audit-log-events-performed-by-an-access-token)
176215
* [AUTOTITLE](/code-security/tutorials/remediate-leaked-secrets/remediating-a-leaked-secret)
177216
* [AUTOTITLE](/rest/credentials/revoke) in the REST API documentation
217+
* [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

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,8 @@ Depending on your account type, the following actions are available:
1717

1818
> [!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.
1919
20+
These actions are recorded in the audit log for any enterprise you belong to, and you will receive an email notification confirming the action.
21+
2022
## Understanding the impact
2123

2224
Before taking action, consider the following:
@@ -58,3 +60,4 @@ After taking action on your credentials:
5860
* [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)
5961
* [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys)
6062
* [AUTOTITLE](/apps/using-github-apps/reviewing-and-revoking-authorization-of-github-apps)
63+
* [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -88,7 +88,7 @@ User access tokens created by a {% data variables.product.prodname_github_app %}
8888

8989
## Token revoked by enterprise owners
9090

91-
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.
91+
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 %}
9292

9393
For more information, see [AUTOTITLE](/enterprise-cloud@latest/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens).
9494

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

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -122,12 +122,20 @@ For exposed or exploited credentials, the most immediate action you can take is
122122
{% ifversion single_user_cred_revocation %}
123123
* **Revoke or delete credentials for a specific user**
124124

125-
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).
125+
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).
126+
127+
* **Revoke or delete credentials of a specific type**
128+
129+
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).
126130

127131
{% endif %}
128132
* **Emergency actions (major incident)**
129133

130-
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).
134+
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).
135+
136+
{% ifversion single_user_cred_revocation %}
137+
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.
138+
{% endif %}
131139

132140
### Restrict access
133141

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

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -46,6 +46,9 @@ You can also filter by a specific event. For example, `action:copilot.cfb_seat_a
4646

4747
To view a record of agent activity, use the `actor:Copilot` search term. See [AUTOTITLE](/copilot/reference/enterprise-administrators/agentic-audit-log-events).
4848

49+
> [!NOTE]
50+
> 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).
51+
4952
## Retaining audit log history
5053

5154
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

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,9 @@ Billing for {% data variables.product.prodname_copilot %} starts when you grant
4242

4343
{% ifversion ghec %}
4444

45-
> [!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).
45+
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).
46+
47+
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).
4648

4749
{% endif %}
4850

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

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -25,3 +25,4 @@ Users must be assigned a seat to access {% data variables.product.prodname_copil
2525
* **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.
2626
* **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.
2727
* **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.
28+
* **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).

0 commit comments

Comments
 (0)