@cryptotaxi247 / documentation / commits / 8511fb6

Position GAT bypass 2FA as replacement for deprecated legacy automation tokens

- Update all GAT bypass 2FA mentions to emphasize it's the modern replacement for legacy automation tokens - Add deprecation notices where GAT bypass 2FA is discussed - Clarify that legacy automation tokens are being deprecated - Updated files: - about-two-factor-authentication.mdx - about-access-tokens.mdx - creating-and-viewing-access-tokens.mdx - using-private-packages-in-a-ci-cd-workflow.mdx - requiring-2fa-for-package-publishing-and-settings-modification.mdx

Karthikeyan Padaikathu committed Oct 30, 2025 at 14:35 UTC 8511fb6a0de5d0d7af98d730f0decf61532b0422

5 files changed +8 -8

content/getting-started/setting-up-your-npm-user-account/about-two-factor-authentication.mdx

+1 -1

@@ -45,7 +45,7 @@ By default, 2FA is enabled for authorization and writes. We will request a secon

46 <Note>

48 -**Note:** [Granular access tokens][granular-tokens] can be configured to bypass 2FA requirements, making them ideal for CI/CD workflows and automation scenarios. When a granular access token is set to bypass 2FA, operations performed with that token will not require additional authentication factors. This provides the same automation benefits as legacy automation tokens, but with enhanced security features like expiration dates, scope restrictions, and IP limitations.

48 +**Note:** [Granular access tokens][granular-tokens] can be configured to bypass 2FA requirements, making them ideal for CI/CD workflows and automation scenarios. When a granular access token is set to bypass 2FA, operations performed with that token will not require additional authentication factors. **Since legacy automation tokens are being deprecated, granular access tokens with 2FA bypass are now the recommended replacement**, providing the same automation benefits with enhanced security features like expiration dates, scope restrictions, and IP limitations.

50 </Note>

content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx

+2 -2

@@ -38,7 +38,7 @@ Legacy tokens are created with the same permissions as the user who created them

38 There are three different types of legacy tokens:

40 - **Read-only**: You can use these tokens to download packages from the registry. These tokens are best for automation and workflows where you are installing packages. For greater security, we recommend using [granular access tokens](#about-granular-access-tokens) instead, which offer fine-grained permissions and configurable expiration.

41 -- **Automation**: You can use these tokens to download packages and install new ones. These tokens are best for automation workflows where you are publishing new packages. Automation tokens automatically bypass 2FA for all operations on npm and are suitable for CI/CD workflows. For greater security and more control, we recommend using [granular access tokens](#about-granular-access-tokens) instead, which allow you to configure 2FA bypass on a per-token basis along with other security features like expiration dates and scope restrictions.

41 +- **Automation**: You can use these tokens to download packages and install new ones. These tokens are best for automation workflows where you are publishing new packages. Automation tokens automatically bypass 2FA for all operations on npm and are suitable for CI/CD workflows. **Legacy automation tokens are being deprecated. We strongly recommend migrating to [granular access tokens](#about-granular-access-tokens) configured with 2FA bypass**, which provide the same automation capabilities with additional security features like expiration dates and scope restrictions.

42 - **Publish**: You can use these tokens to download packages, install packages, and update user and package settings. We recommend using them for interactive workflows such as a CLI. If 2FA is enabled on your account, publish tokens will require 2FA to execute sensitive operations on npm.

44 Legacy tokens do not have an expiration date. It is important to be aware of your tokens and keep them protected for account security. For more information, see "[Securing your token][secure-token]."

@@ -54,7 +54,7 @@ Granular access tokens are the modern, recommended token type for npm authentica

54 - Select between **read-only** or **read and write** access

55 - Configure whether the token can bypass two-factor authentication (2FA) requirements

57 -Granular access tokens provide enhanced security compared to legacy automation tokens while maintaining the same flexibility for CI/CD workflows. They can be configured to bypass 2FA requirements when needed, making them ideal for CI/CD workflows and automation scenarios where interactive 2FA prompts are not feasible. When a granular access token is set to bypass 2FA, it will not require additional authentication factors when performing operations on npm, providing the same automation benefits as legacy automation tokens but with additional security controls.

57 +Granular access tokens provide enhanced security compared to legacy automation tokens while maintaining the same flexibility for CI/CD workflows. They can be configured to bypass 2FA requirements when needed, making them ideal for CI/CD workflows and automation scenarios where interactive 2FA prompts are not feasible. When a granular access token is set to bypass 2FA, it will not require additional authentication factors when performing operations on npm, **providing a modern replacement for legacy automation tokens** with additional security controls such as expiration dates, scope restrictions, and IP address limitations.

59 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.

content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx

+2 -2

@@ -12,7 +12,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc

13 <Note>

15 -**Note:** For greater security and flexibility, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy tokens. Granular access tokens provide fine-grained permissions, expiration dates, IP restrictions, and configurable 2FA bypass for CI/CD workflows - offering all the benefits of legacy automation tokens with enhanced security controls. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which eliminates the need for long-lived tokens entirely.

15 +**Note:** For greater security and flexibility, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy tokens. Granular access tokens provide fine-grained permissions, expiration dates, IP restrictions, and configurable 2FA bypass for CI/CD workflows - **offering a modern replacement for legacy automation tokens** with enhanced security controls. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which eliminates the need for long-lived tokens entirely.

17 </Note>

@@ -29,7 +29,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc

29 4. Select the type of access token:

30 - **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. For better security, use [granular access tokens](#creating-granular-access-tokens-on-the-website) which allow you to restrict access to specific packages and set expiration dates.

32 - - **Automation**: An automation token can download packages and publish new ones, and it automatically bypasses two-factor authentication (2FA) for all operations on npm. You can use an automation token in continuous integration workflows and other automation systems to publish packages without entering a one-time passcode. **Note:** For enhanced security in CI/CD workflows, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) which allow you to configure 2FA bypass on a per-token basis, set expiration dates, and restrict access to specific packages, or consider using [trusted publishing](/trusted-publishers) which eliminates the need for long-lived tokens entirely.

32 + - **Automation**: An automation token can download packages and publish new ones, and it automatically bypasses two-factor authentication (2FA) for all operations on npm. You can use an automation token in continuous integration workflows and other automation systems to publish packages without entering a one-time passcode. **Note: Legacy automation tokens are being deprecated. We recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) with the "Bypass two-factor authentication" option enabled**, which provides the same 2FA bypass capability with additional security features like expiration dates and scope restrictions. Alternatively, consider using [trusted publishing](/trusted-publishers) which eliminates the need for long-lived tokens entirely.

34 - **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.

content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx

+1 -1

@@ -37,7 +37,7 @@ For more information on creating access tokens, including CIDR-whitelisted token

38 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.

40 -If trusted publishing is not available for your CI/CD provider, you may create a [granular access token][create-token] configured to bypass 2FA on the website. Granular access tokens provide the same 2FA bypass capability as legacy automation tokens, but with additional security features like expiration dates, scope restrictions, and IP address limitations. Alternatively, you can use a legacy [automation token][create-token], though granular access tokens are recommended for enhanced security. Both token types will allow you to publish even if you have two-factor authentication enabled on your account.

40 +If trusted publishing is not available for your CI/CD provider, you may create a [granular access token][create-token] configured to bypass 2FA on the website. **Granular access tokens with 2FA bypass are the recommended replacement for legacy automation tokens**, providing the same 2FA bypass capability with additional security features like expiration dates, scope restrictions, and IP address limitations. Alternatively, you can use a legacy [automation token][create-token], though granular access tokens are recommended for enhanced security. Both token types will allow you to publish even if you have two-factor authentication enabled on your account.

42 ### Interactive workflows

content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx

+2 -2

@@ -6,7 +6,7 @@ import shared from '~/shared.js'

7 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]".

9 -You may also choose to allow publishing with either two-factor authentication _or_ with tokens configured to bypass 2FA (such as legacy [automation tokens][creating-automation-token] or [granular access tokens][creating-granular-access-token] with bypass 2FA enabled). This lets you configure tokens in a CI/CD workflow while still requiring two-factor authentication from interactive publishes. We recommend using granular access tokens for enhanced security, as they provide the same 2FA bypass capability as automation tokens but with additional security features like expiration dates and scope restrictions.

9 +You may also choose to allow publishing with either two-factor authentication _or_ with tokens configured to bypass 2FA (such as legacy [automation tokens][creating-automation-token] or [granular access tokens][creating-granular-access-token] with bypass 2FA enabled). This lets you configure tokens in a CI/CD workflow while still requiring two-factor authentication from interactive publishes. **Since legacy automation tokens are being deprecated, we recommend using granular access tokens with 2FA bypass**, as they provide the same automation capability with additional security features like expiration dates and scope restrictions.

11 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.

@@ -27,7 +27,7 @@ For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), w

27 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.

29 2. **Require two-factor authentication or automation tokens or granular access token**

30 - 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 legacy [automation token][creating-automation-token] or a [granular access token][creating-granular-access-token] configured to bypass 2FA and use that to publish. A second factor is _not_ required when using a token configured to bypass 2FA, making it useful for continuous integration and continuous deployment workflows. We recommend using granular access tokens for better security, as they provide the same 2FA bypass capability with additional controls like expiration dates and scope restrictions.

30 + 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 legacy [automation token][creating-automation-token] or a [granular access token][creating-granular-access-token] configured to bypass 2FA and use that to publish. A second factor is _not_ required when using a token configured to bypass 2FA, making it useful for continuous integration and continuous deployment workflows. **Since legacy automation tokens are being deprecated, we recommend using granular access tokens with 2FA bypass**, which provide the same automation capability with better security controls like expiration dates and scope restrictions.

32 3. **Require two-factor authentication and disallow tokens**

33 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 configured to bypass 2FA cannot be used to publish packages.