diff --git a/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md b/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md
new file mode 100644
index 0000000000..e38c94ce48
--- /dev/null
+++ b/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80-1.md
@@ -0,0 +1,28 @@
+---
+Title: Testing Enforced Updating
+ID: MASTG-TEST-0x80-1
+Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
+Platform: android
+MASVS v1: ['MSTG-ARCH-9']
+MASVS v2: ['MASVS-CODE-2']
+type: [dynamic]
+---
+
+## Overview
+
+When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.
+
+## Steps
+
+1. Obtain a MitM position between the application and its backend (see @MASTG-TECH-0011).
+2. Identify if version information is sent to the backend. This can be as part of a header, the URL, a URL parameter or the HTTP body.
+3. Interact with the backend to see if different version numbers trigger different responses.
+4. If a different response can be identified, modify an active request with the old version number to examine how the application reacts to the new backend response.
+
+## Observation
+
+The server responds differently to older versions.
+
+## Evaluation
+
+The test case fails if the application does not send its version information to the backend.
diff --git a/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md b/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md
new file mode 100644
index 0000000000..220846c2ff
--- /dev/null
+++ b/tests-beta/android/MASVS-CODE/MASTG-TEST-0x80.md
@@ -0,0 +1,26 @@
+---
+Title: Testing Enforced Updating
+ID: MASTG-TEST-0x80
+Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
+Platform: android
+MASVS v1: ['MSTG-ARCH-9']
+MASVS v2: ['MASVS-CODE-2']
+type: [static]
+---
+
+## Overview
+
+When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.
+
+## Steps
+
+1. Examine the startup flow of the application. Identify if the application calls out to a backend with the application's version information included.
+2. Examine if the application can handle a specific response from the backend indicating that the application must be updated. For example, the application might evaluate the response from the backend and show a specific error message. Note that the error message can also come from the backend, so the lack of a custom error message in the application does not mean that the feature isn't implemented.
+
+## Observation
+
+The application contains specific logic to handle a force-update event. The user may be able to ignore the prompt and continue using the application, or they may be unable to use the application without updating.
+
+## Evaluation
+
+The test case fails if the application does not contain any logic to handle a forced application update. Additionally, the test case fails if the application informs the user that they must update, but the user can ignore the prompt and still use the application.
diff --git a/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-2.md b/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-2.md
new file mode 100644
index 0000000000..ae64f962fb
--- /dev/null
+++ b/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-2.md
@@ -0,0 +1,28 @@
+---
+Title: Testing Enforced Updating
+ID: MASTG-TEST-0x80
+Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
+Platform: ios
+MASVS v1: ['MSTG-ARCH-9']
+MASVS v2: ['MASVS-CODE-2']
+type: [dynamic]
+---
+
+## Overview
+
+When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.
+
+## Steps
+
+1. Obtain a MitM position between the application and its backend (see @MASTG-TECH-0063).
+2. Identify if version information is sent to the backend. This can be as part of a header, the URL, a URL parameter or the HTTP body.
+3. Interact with the backend to see if different version numbers trigger different responses.
+4. If a different response can be identified, modify an active request with the old version number to examine how the application reacts to the new backend response.
+
+## Observation
+
+The server responds differently to older versions.
+
+## Evaluation
+
+The test case fails if the application does not send its version information to the backend.
diff --git a/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md b/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md
new file mode 100644
index 0000000000..868cf9ab10
--- /dev/null
+++ b/tests-beta/ios/MASVS-CODE/MASVS-TEST-0x80-3.md
@@ -0,0 +1,26 @@
+---
+Title: Testing Enforced Updating
+ID: MASTG-TEST-0x80
+Link: https://mas.owasp.org/MASTG/tests/android/MASVS-CODE/MASTG-TEST-0080/
+Platform: ios
+MASVS v1: ['MSTG-ARCH-9']
+MASVS v2: ['MASVS-CODE-2']
+type: [static]
+---
+
+## Overview
+
+When a vulnerability is found in the app, it should be possible to force the user to update the application to continue using it.
+
+## Steps
+
+1. Examine the startup flow of the application. Identify if the application calls out to a backend with the application's version information included.
+2. Examine if the application can handle a specific response from the backend indicating that the application must be updated. For example, the application might evaluate the response from the backend and show a specific error message. Note that the error message can also come from the backend, so the lack of a custom error message in the application does not mean that the feature isn't implemented.
+
+## Observation
+
+The application contains specific logic to handle a force-update event. The user may be able to ignore the prompt and continue using the application, or they may be unable to use the application without updating.
+
+## Evaluation
+
+The test case fails if the application does not contain any logic to handle a forced application update. Additionally, the test case fails if the application informs the user that they must update, but the user can ignore the prompt and still use the application.