diff --git a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-the-dependency-review-action.md b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-the-dependency-review-action.md
index 4377c500ea70..bcb34d7611aa 100644
--- a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-the-dependency-review-action.md
+++ b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-the-dependency-review-action.md
@@ -36,7 +36,7 @@ Here is a list of common configuration options. For more information, and a full
 | `allow-licenses` | {% octicon "x" aria-label="Optional" %} | Contains a list of allowed licenses. You can find the possible values for this parameter in the [Licenses](/rest/licenses) page of the API documentation.</br>The action will fail on pull requests that introduce dependencies with licenses that do not match the list.|
 | {% endif %} |
 | {% ifversion dependency-review-action-licenses %} |
-| `deny-licenses` | {% octicon "x" aria-label="Optional" %} | Contains a list of prohibited licenses. You can find the possible values for this parameter in the [Licenses](/rest/licenses) page of the API documentation.</br>The action will fail on pull requests that introduce dependencies with licenses that match the list.|
+| `deny-licenses` | {% octicon "x" aria-label="Optional" %} | ⚠️ This option is up for possible removal in the next major release. Contains a list of prohibited licenses. You can find the possible values for this parameter in the [Licenses](/rest/licenses) page of the API documentation.</br>The action will fail on pull requests that introduce dependencies with licenses that match the list.|
 | {% endif %} |
 | `fail-on-scopes` | {% octicon "x" aria-label="Optional" %} | Contains a list of strings representing the build environments you want to support (`development`, `runtime`, `unknown`). </br>The action will fail on pull requests that introduce vulnerabilities in the scopes that match the list.|
 | `comment-summary-in-pr` | {% octicon "x" aria-label="Optional" %} | Enable or disable the reporting of the review summary as a comment in the pull request. If enabled, you must give the workflow or job the `pull-requests: write` permission. With each execution, a new comment will overwrite the existing one.|
diff --git a/content/code-security/tutorials/secure-your-dependencies/customizing-your-dependency-review-action-configuration.md b/content/code-security/tutorials/secure-your-dependencies/customizing-your-dependency-review-action-configuration.md
index ff950fbf4b71..6ce90a837a44 100644
--- a/content/code-security/tutorials/secure-your-dependencies/customizing-your-dependency-review-action-configuration.md
+++ b/content/code-security/tutorials/secure-your-dependencies/customizing-your-dependency-review-action-configuration.md
@@ -73,16 +73,16 @@ You can block code containing vulnerable dependencies from ever being merged by
 
 ## Step 3: Adding licenses to block
 
-Vulnerabilities aren’t the only reason you might want to block a dependency. If your organization has restrictions on what sorts of licenses you can use, you can use dependency review to enforce those policies with the `deny-licenses` option. In this step, we will add a customization that will break the build if the pull request introduces a dependency that contains the LGPL-2.0 or BSD-2-Clause license.
+Vulnerabilities aren’t the only reason you might want to block a dependency. If your organization has restrictions on what sorts of licenses you can use, you can use dependency review to enforce those policies with the `allow-licenses` option. In this step, we will add a customization that will break the build if the pull request introduces a dependency that not contain the LGPL-2.0 or BSD-2-Clause license.
 
-1. Add the `deny-licenses` option to the end of the `dependency-review.yml` file:
+1. Add the `allow-licenses` option to the end of the `dependency-review.yml` file:
 
    ```yaml copy
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
-             deny-licenses: LGPL-2.0, BSD-2-Clause
+             allow-licenses: LGPL-2.0, BSD-2-Clause
    ```
 
 ## Step 4: Adding scopes
@@ -96,7 +96,7 @@ Finally, we'll use the `fail-on-scopes` option to prevent merging vulnerable dep
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
-             deny-licenses: LGPL-2.0, BSD-2-Clause
+             allow-licenses: LGPL-2.0, BSD-2-Clause
              fail-on-scopes: development
    ```
 
@@ -126,7 +126,7 @@ jobs:
         uses: actions/dependency-review-action@v4
         with:
           fail-on-severity: moderate
-          deny-licenses: LGPL-2.0, BSD-2-Clause
+          allow-licenses: LGPL-2.0, BSD-2-Clause
           fail-on-scopes: development
 ```
 
@@ -140,8 +140,6 @@ When customizing your dependency review configuration, there are some best pract
 
 * Choose block lists over allow lists. It is more practical to compile a list of the "really bad" dependencies you want to block than to create an inclusive list of all the libraries you want to allow.
 
-* Choose to block licenses instead of specifying which licenses to allow. There are a wide variety of licenses out there, so it's usually more practical to exclude those you know are incompatible with current licenses than it is to compile a complete list of compatible licenses.
-
 * Choose `fail-on-severity`. Failing based on the severity of a vulnerability is a good way to balance the need for security with the need to create low-friction experiences for developers.
 
 ## Further reading