From 25ffc7ad5dfed5491a1c27c90bd8b727e3a14d0d Mon Sep 17 00:00:00 2001 From: Jithin Prabhakaran Girija <141764922+jpg619@users.noreply.github.com> Date: Mon, 3 Nov 2025 11:23:28 -0500 Subject: [PATCH 1/7] [update]: `legacy` access token creation workflow from access tokens documentation (#1756) ### Summary: Added notes on deprecated legacy access token references and removed few documentation due to deprecation ### File Changes (3 files) 1. `content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx` 2. `content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx` 3. `content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx` ### Changes Made - Added `note` for legacy token creation workflow from access tokens documentation --------- Co-authored-by: Di Hei --- .../about-access-tokens.mdx | 15 +++-- .../creating-and-viewing-access-tokens.mdx | 62 +------------------ ...g-private-packages-in-a-ci-cd-workflow.mdx | 6 ++ 3 files changed, 17 insertions(+), 66 deletions(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index aa174681a5d..b3ce4b9b983 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -13,10 +13,7 @@ redirect_from: An access token is an alternative to using your username and password for authenticating to npm when using the API or the npm command-line interface (CLI). An access token is a hexadecimal string that you can use to authenticate, and which gives you the right to install and/or publish your modules. -There are two types of access tokens available: - -- [Legacy tokens](#about-legacy-tokens) -- [Granular access tokens](#about-granular-access-tokens) +As of November 2025, access tokens can only be [Granular access tokens](#about-granular-access-tokens). Legacy access tokens are removed. You can create access tokens to give other tools (such as continuous integration testing environments) access to your npm packages. For example, GitHub Actions provides the ability to store [secrets](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets), such as access tokens, that you can then use to authenticate. When your workflow runs, it will be able to complete npm tasks as you, including installing private packages you can access. @@ -25,13 +22,19 @@ You can work with tokens from the web or the CLI, whichever is easiest. What you npm token commands let you: - View tokens for easier tracking and management -- Create new legacy tokens +- Create new legacy tokens (deprecated) - Limit access according to IP address ranges (CIDR) - Delete/revoke tokens For more information on creating and viewing access tokens on the web and CLI, see "[Creating and viewing access tokens][create-token]". -## About legacy tokens +## About legacy tokens (Deprecated) + + + +**Warning:** Legacy access tokens are removed as of November 2025. + + Legacy tokens are created with the same permissions as the user who created them. The npm CLI automatically generates and uses a publish token when you run `npm login`. diff --git a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx index 4e1501ed455..33bdb6061ba 100644 --- a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx @@ -8,37 +8,6 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc ## Creating access tokens -### Creating legacy tokens on the website - - - -**Note:** For greater security, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy read-only tokens or legacy automation tokens. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which eliminates the need for long-lived tokens entirely. - - - -1. In the upper right corner of the page, click your profile picture, then click **Access Tokens**. - - - -2. Click **Generate New Token**, then select **legacy token** from the dropdown menu. - - - -3. (Optional) Name your token. - -4. Select the type of access token: - - **Read-only**: A read-only token can only be used to download packages from the registry. It will have permission to read any private package that you have access to. This is recommended for automation and workflows where you are installing packages, but not publishing new ones. - - - **Automation**: An automation token can download packages and publish new ones, but if you have two-factor authentication (2FA) configured on your account, it will **not** be enforced. You can use an automation token in continuous integration workflows and other automation systems to publish a package even when you cannot enter a one-time passcode. For enhanced security in CI/CD workflows, consider using [trusted publishing](/trusted-publishers) instead, which eliminates the need for long-lived tokens. - - - **Publish**: A publish token can perform any action on your behalf, including downloading packages, publishing packages, and changing user settings or package settings. If you have two-factor authentication configured on your account, you will be required to enter a one-time passcode when using a publish token. This is recommended for interactive workflows such as a CLI. - - - -5. Click **Generate Token**. - -6. Copy the token from the top of page. - ### Creating granular access tokens on the website 1. In the upper right corner of the page, click your profile picture, then click **Access Tokens**. @@ -83,38 +52,12 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc ### Creating tokens with the CLI -You can create tokens with **read-only** permissions or **read and publish** permissions with the CLI. - -**Note:** You cannot create legacy automation tokens or granular access tokens from the CLI. You must use the website to generate these types of tokens. For more information, see "[Creating legacy tokens on the website](#creating-legacy-tokens-on-the-website)" and "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." +**Note:** You cannot create granular access tokens from the CLI. You must use the website to generate these types of tokens. For more information, see "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." -- **Read-only:** Tokens that allow installation and distribution only, but no publishing or other rights associated with your account. -- **Publish:** The default setting for new tokens, and most permissive token type. Publish tokens allow installation, distribution, modification, publishing, and all rights that you have on your account. - -In addition, you can specify that the token is only valid for a specific IPv4 address range, using [CIDR][cidr-wiki] notation. The token will only be valid when used from the specified IP addresses. - -1. To create a new token, on the command line, run: - - `npm token create` for a read and publish token - - `npm token create --read-only` for a read-only token - - `npm token create --cidr=[list]` for a CIDR-restricted read and publish token. For example, `npm token create --cidr=192.0.2.0/24` - - `npm token create --read-only --cidr=[list]` for a CIDR-restricted read-only token -2. When prompted, enter your password. -3. If you have enabled [two-factor authentication][tfa], when prompted, enter a one-time password. -4. Copy the token from the **token** field in the command output. - -#### CIDR-restricted token errors - -If the CIDR string you enter is invalid or in an inappropriate format, you will get an error similar to the one below: - -``` -npm ERR! CIDR whitelist contains invalid CIDR entry: X.X.X.X./YY,Z.Z.. . . -``` - -Make sure you are using a valid IPv4 range and try creating the token again. - ## Viewing access tokens @@ -141,8 +84,7 @@ npm token list - **id:** Use the token ID to refer to the token in commands. - **token:** The first digits of the actual token. -- **create:** Date the token was created. -- **readonly:** If yes, indicates a read-only token. If no, indicates a token with both read and publish permissions. +- **created:** Date the token was created. - **CIDR whitelist:** Restricts token use by IP address. [tfa]: about-two-factor-authentication diff --git a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx index 0d6eb12ca03..1b5642610a3 100644 --- a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx +++ b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx @@ -27,6 +27,12 @@ When generating an access token for use in a continuous integration environment, If you use a legacy token instead, by default, `npm token create` will generate a token with both read and write permissions. We recommend creating a read-only token: + + +**Warning:** Legacy access tokens are removed as of November 2025. + + + ``` npm token create --read-only ``` From 8bf878f27e58e35c3ca11cedd746506c857c97a9 Mon Sep 17 00:00:00 2001 From: Karen Li <47998177+karenjli@users.noreply.github.com> Date: Mon, 3 Nov 2025 12:05:54 -0500 Subject: [PATCH 2/7] docs: Update GAT documentation (#1762) This PR updates GAT related documentation to cover how 2FA will be handled for GATs --- .../about-access-tokens.mdx | 3 ++ .../creating-and-viewing-access-tokens.mdx | 16 ++++--- .../revoking-access-tokens.mdx | 14 +++++- ...g-private-packages-in-a-ci-cd-workflow.mdx | 44 +++++++++---------- ...e-publishing-and-settings-modification.mdx | 20 ++++++--- 5 files changed, 62 insertions(+), 35 deletions(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index b3ce4b9b983..87c8f52abd1 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -55,10 +55,13 @@ Granular access tokens allow you to restrict access provided to the token based - Set a token expiration date - Limit token access based on IP address ranges - Select between **read-only** or **read and write** access +- Configure a token to **Bypass 2FA** requirements You can create up to 1000 granular access tokens on your npm account. You can set how long your token is valid for, at least one day in the future. Each token can access up to 50 organizations, and up to either 50 packages, 50 scopes, or a combination of 50 packages and scopes. Access tokens are tied to users’ permission; hence it cannot have more permission than the user at any point in time. If a user has their access revoked from a package or an org., their granular access token also will have its access revoked from those packages or org. When you give a token access to an organization, the token can only be used for managing organization settings and teams or users associated with the organization. It does not give the token the right to publish packages managed by the organization. +The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token. + [create-token]: creating-and-viewing-access-tokens [secure-token]: using-private-packages-in-a-ci-cd-workflow#securing-your-token diff --git a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx index 33bdb6061ba..b389bb567e7 100644 --- a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx @@ -22,13 +22,17 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc 4. (Optional) In the **Description** field, enter a description for your token. -5. In the **Expiration** field, enter a token expiration period. The date must be at least 1 day in the future. +5. (Optional) Check the **Bypass two-factor authentication** checkbox if you want this token to bypass 2FA requirements for write actions. + - This setting is unchecked (false) by default + - By checking this box, the token will bypass 2FA for write actions even if 2FA is enabled at the account or package level -6. (Optional) In the **Allowed IP Ranges** field, enter IP address ranges to restrict your access token to. You must use [CIDR][cidr-wiki] notation to enter IP address ranges. To add more than one allowed IP range, click **Add IP Range** and enter an IP range in the new text field. +6. In the **Expiration** field, enter a token expiration period. The date must be at least 1 day in the future. + +7. (Optional) In the **Allowed IP Ranges** field, enter IP address ranges to restrict your access token to. You must use [CIDR][cidr-wiki] notation to enter IP address ranges. To add more than one allowed IP range, click **Add IP Range** and enter an IP range in the new text field. -7. (Optional) In the **Packages and scopes** section, configure your token's access to packages and scopes. +8. (Optional) In the **Packages and scopes** section, configure your token's access to packages and scopes. - In the **Permissions** dropdown menu, select **No access**, **Read-only**, or **Read and write**. - Under **Select Packages**, select either: - **All Packages** to grant the token access to all packages the user account has access to. @@ -36,7 +40,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc -8. (Optional) In the **Organizations** section, configure your token's access to organizations. +9. (Optional) In the **Organizations** section, configure your token's access to organizations. - In the **Permissions** dropdown menu, select **No access**, **Read-only**, or **Read and write**. - Under **Select organizations**, select the organizations you want to grant your token access to. @@ -44,11 +48,11 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc _**Note**: When you give a token access to an organization, the token can only be used for managing organization settings and teams or users associated with the organization. It does not give the token the right to publish packages managed by the organization._ -9. Review the token summary, then click **Generate Token**. +10. Review the token summary, then click **Generate Token**. -10. Copy the token from the top of page. +11. Copy the token from the top of page. ### Creating tokens with the CLI diff --git a/content/integrations/integrating-npm-with-external-services/revoking-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/revoking-access-tokens.mdx index 1db2daf624e..6d500159d72 100644 --- a/content/integrations/integrating-npm-with-external-services/revoking-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/revoking-access-tokens.mdx @@ -4,7 +4,19 @@ redirect_from: - /revoking-authentication-tokens --- -To keep your account and packages secure, we strongly recommend revoking (deleting) tokens you no longer need or that have been compromised. You can revoke any token you have created. +To keep your account and packages secure, we strongly recommend revoking (deleting) tokens you no longer need or that have been compromised. You can revoke any token you have created, including granular access tokens. + +## Revoking tokens on the website + +1. In the upper right corner of the page, click your profile picture, then click **Access Tokens**. + +2. Find the token you want to delete in the token list. + +3. Click the **×** button next to the token, or select multiple tokens and click **Delete Selected Tokens**. + +4. Confirm the deletion when prompted. + +## Revoking tokens using the CLI 1. To see a list of your tokens, on the command line, run: diff --git a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx index 1b5642610a3..21639230c6f 100644 --- a/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx +++ b/content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx @@ -25,7 +25,13 @@ Create a new access token that will be used only to access npm packages from a C When generating an access token for use in a continuous integration environment, we recommend using a granular access token with limited access to provide greater security. -If you use a legacy token instead, by default, `npm token create` will generate a token with both read and write permissions. We recommend creating a read-only token: +For most CI workflows that only install dependencies and run tests, a **read-only** granular access token is sufficient and most secure. + + + +**Note:** If your CI workflow requires write operations (such as publishing test packages), you may need a granular access token with read and write permissions and bypass 2FA enabled to prevent automated workflows from being blocked by 2FA prompts. However, we strongly recommend using read-only tokens whenever possible and reserving bypass 2FA for deployment workflows only. + + @@ -33,42 +39,34 @@ If you use a legacy token instead, by default, `npm token create` will generate -``` -npm token create --read-only -``` - -For more information on creating access tokens, including CIDR-whitelisted tokens, see "[Creating an access token][create-token]". +For more information on creating granular access tokens, including CIDR-whitelisted tokens, see "[Creating and viewing access tokens][create-token]". ### Continuous deployment For publishing packages in continuous deployment environments, we strongly recommend using [trusted publishing](/trusted-publishers) when available, as it provides enhanced security without requiring token management. -If trusted publishing is not available for your CI/CD provider, you may create an [automation token][create-token] on the website. This will allow you to publish even if you have two-factor authentication enabled on your account. +If trusted publishing is not available for your CI/CD provider, you can create a [granular access token with bypass 2FA enabled][create-token] on the website. This will allow you to publish even if you have two-factor authentication enabled on your account. -### Interactive workflows + -If your workflow produces a package, but you publish it manually after validation, then you will want to create a token with read and write permissions, which are granted with the standard token creation command: +**Security considerations for bypass 2FA:** -``` -npm token create -``` +- Only enable bypass 2FA when necessary for automated publishing workflows +- Use restrictive permissions and short expiration dates +- Consider IP address restrictions and regular token rotation +- Use trusted publishing instead of bypass 2FA tokens whenever possible -### CIDR whitelists + -For increased security, you may use a CIDR-whitelisted token that can only be used from a certain IP address range. You can use a CIDR whitelist with a read and publish token or a read-only token: +### Interactive workflows -``` -npm token create --cidr=[list] -npm token create --read-only --cidr=[list] -``` +If your workflow produces a package, but you publish it manually after validation, then you will want to create a granular access token with read and write permissions. See "[Creating and viewing access tokens][create-token]" for instructions. -Example: +### CIDR whitelists -``` -npm token create --cidr=192.0.2.0/24 -``` +For increased security, you may use a CIDR-whitelisted granular access token that can only be used from a certain IP address range. You can configure IP address restrictions when creating your granular access token on the website. -For more information, see "[Creating and viewing authentication tokens][create-token]". +For more information, see "[Creating and viewing access tokens][create-token]". ## Set the token as an environment variable on the CI/CD server diff --git a/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx b/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx index 7e3b3d0bccc..4aee6a2788e 100644 --- a/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx +++ b/content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx @@ -6,10 +6,21 @@ import shared from '~/shared.js' To protect your packages, as a package publisher, you can require everyone who has write access to a package to have two-factor authentication (2FA) enabled. This will require that users provide 2FA credentials in addition to their login token when they publish the package. For more information, see "[Configuring two-factor authentication][config-2fa]". -You may also choose to allow publishing with either two-factor authentication _or_ with [automation tokens][creating-automation-token]. This lets you configure automation tokens in a CI/CD workflow, but requires two-factor authentication from interactive publishes. +You may also choose to allow publishing with either two-factor authentication _or_ with [granular access tokens with bypass 2FA enabled][creating-granular-access-token]. This lets you configure tokens in a CI/CD workflow, but requires two-factor authentication from interactive publishes. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which provides secure, token-free publishing that automatically enforces strong authentication without requiring manual token management. + + +**Important notes about granular access tokens:** + +- Bypass 2FA configuration is set at token creation +- When **bypass 2FA is disabled**: The system will check account-level and package-level settings to determine if 2FA is required +- When **bypass 2FA is enabled**: The token will bypass all 2FA requirements at all times, regardless of account-level or package-level 2FA settings +- When **Require two-factor authentication and disallow tokens** is selected at the package level, granular access tokens cannot be used regardless of their bypass 2FA setting + + + ## Configuring two-factor authentication 1. <>{shared['user-login'].text} @@ -26,16 +37,15 @@ For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), w 1. **Dont require two-factor authentication** With this option, a maintainer can publish a package or change the package settings whether they have two-factor authentication enabled or not. This is the least secure setting. - 2. **Require two-factor authentication or automation tokens or granular access token** - With this option, maintainers must have two-factor authentication enabled for their account. If they publish a package interactively, using the `npm publish` command, they will be required to enter 2FA credentials when they perform the publish. However, maintainers may also create an [automation token][creating-automation-token] or a [granular access token][creating-granular-access-token] and use that to publish. A second factor is _not_ required when using a token, making it useful for continuous integration and continuous deployment workflows. + 2. **Require two-factor authentication or granular access tokens** + With this option, maintainers must have two-factor authentication enabled for their account. If they publish a package interactively, using the `npm publish` command, they will be required to enter 2FA credentials when they perform the publish. However, maintainers may also create a [granular access token with bypass 2FA enabled][creating-granular-access-token] and use that to publish. A second factor is _not_ required when using these specific token types, making them useful for continuous integration and continuous deployment workflows. 3. **Require two-factor authentication and disallow tokens** - With this option, a maintainer must have two-factor authentication enabled for their account, and they must publish interactively. Maintainers will be required to enter 2FA credentials when they perform the publish. Automation tokens and granular access tokens cannot be used to publish packages. + With this option, a maintainer must have two-factor authentication enabled for their account, and they must publish interactively. Maintainers will be required to enter 2FA credentials when they perform the publish. Granular access tokens cannot be used to publish packages, regardless of their bypass 2FA setting. 5. Click **Update Package Settings**. [config-2fa]: configuring-two-factor-authentication -[creating-automation-token]: creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website [creating-granular-access-token]: creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website From accd8c18c767ecd1b5fb4afc4662ff2e060535f1 Mon Sep 17 00:00:00 2001 From: Karen Li Date: Tue, 4 Nov 2025 13:30:41 -0500 Subject: [PATCH 3/7] Update legacy token removed warning message --- .../about-access-tokens.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index 87c8f52abd1..a7a65162ea2 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -32,7 +32,7 @@ For more information on creating and viewing access tokens on the web and CLI, s -**Warning:** Legacy access tokens are removed as of November 2025. +**Warning:** Legacy access tokens were removed on November 5, 2025. From 26239c213014b935dbb5403090fae002a5a5b99a Mon Sep 17 00:00:00 2001 From: Karen Li Date: Tue, 4 Nov 2025 13:32:42 -0500 Subject: [PATCH 4/7] Update based on PR comments --- .../about-access-tokens.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index a7a65162ea2..09d4c845d73 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -13,7 +13,7 @@ redirect_from: An access token is an alternative to using your username and password for authenticating to npm when using the API or the npm command-line interface (CLI). An access token is a hexadecimal string that you can use to authenticate, and which gives you the right to install and/or publish your modules. -As of November 2025, access tokens can only be [Granular access tokens](#about-granular-access-tokens). Legacy access tokens are removed. +As of November 2025, only [Granular access tokens](#about-granular-access-tokens) are supported. Legacy access tokens have been removed. You can create access tokens to give other tools (such as continuous integration testing environments) access to your npm packages. For example, GitHub Actions provides the ability to store [secrets](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets), such as access tokens, that you can then use to authenticate. When your workflow runs, it will be able to complete npm tasks as you, including installing private packages you can access. From 1a7a1cdadbda57157104eed3ced73139b59d65b1 Mon Sep 17 00:00:00 2001 From: Karen Li Date: Tue, 4 Nov 2025 15:04:21 -0500 Subject: [PATCH 5/7] Add note about npm token CLI command --- .../creating-and-viewing-access-tokens.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx index b389bb567e7..2af6ee2ab4f 100644 --- a/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx @@ -58,7 +58,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc -**Note:** You cannot create granular access tokens from the CLI. You must use the website to generate these types of tokens. For more information, see "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." +**Note:** You cannot create granular access tokens from the CLI currently. You must use the website to generate these types of tokens. Support for creating granular access tokens via `npm token` CLI command will be added in the future. For more information, see "[Creating granular access tokens on the website](#creating-granular-access-tokens-on-the-website)." From 3171c06d3227621d4674ce334a30760681a0c2f8 Mon Sep 17 00:00:00 2001 From: Karen Li Date: Tue, 4 Nov 2025 15:19:41 -0500 Subject: [PATCH 6/7] Add warning to 2FA bypass --- .../about-access-tokens.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index 09d4c845d73..cf7cfc42519 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -61,7 +61,7 @@ You can create up to 1000 granular access tokens on your npm account. You can se When you give a token access to an organization, the token can only be used for managing organization settings and teams or users associated with the organization. It does not give the token the right to publish packages managed by the organization. -The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token. +The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token. Do not set Bypass 2FA to true if a package or organization requires fully enforced 2FA. [create-token]: creating-and-viewing-access-tokens [secure-token]: using-private-packages-in-a-ci-cd-workflow#securing-your-token From 270567c8c010fa968d70c79fb2069d645ce4716c Mon Sep 17 00:00:00 2001 From: Karen Li Date: Tue, 4 Nov 2025 15:33:13 -0500 Subject: [PATCH 7/7] Fix linting --- .../about-access-tokens.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx index cf7cfc42519..561872712be 100644 --- a/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx +++ b/content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx @@ -61,7 +61,7 @@ You can create up to 1000 granular access tokens on your npm account. You can se When you give a token access to an organization, the token can only be used for managing organization settings and teams or users associated with the organization. It does not give the token the right to publish packages managed by the organization. -The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token. Do not set Bypass 2FA to true if a package or organization requires fully enforced 2FA. +The Bypass 2FA capability applies to tokens with write access and is set to false by default at token creation. When the Bypass 2FA option is set to true, this setting takes precedence over account-level and package-level 2FA settings. This means that even if account-level 2FA is enabled and/or package-level 2FA is required, 2FA will still be bypassed when using the token. Do not set Bypass 2FA to true if a package or organization requires fully enforced 2FA. [create-token]: creating-and-viewing-access-tokens [secure-token]: using-private-packages-in-a-ci-cd-workflow#securing-your-token