diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md
index 94f474bf77..411f38532f 100644
--- a/5.0/en/0x12-V3-Session-management.md
+++ b/5.0/en/0x12-V3-Session-management.md
@@ -63,7 +63,6 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these
 | **3.5.4** | [ADDED] Verify that stateless tokens are checked for expiration before processing them further. | ✓ | ✓ | ✓ | 613 | |
 | **3.5.5** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 | |
 | **3.5.6** | [ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience. | ✓ | ✓ | ✓ | 287 | |
-| **3.5.7** | [ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user. | ✓ | ✓ | ✓ | 613 | |
 
 ## V3.6 Federated Re-authentication
 
diff --git a/5.0/en/0x12-V4-Access-Control.md b/5.0/en/0x12-V4-Access-Control.md
index 0ce6e1b41f..321f09def1 100644
--- a/5.0/en/0x12-V4-Access-Control.md
+++ b/5.0/en/0x12-V4-Access-Control.md
@@ -19,6 +19,7 @@ Access control deficiencies are unlikely to be discovered using generic automate
 | **4.1.3** | Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. | ✓ | ✓ | ✓ | 285 |
 | **4.1.4** | [DELETED, DUPLICATE OF 4.1.3] | | | | |
 | **4.1.5** | [GRAMMAR] Verify that access controls fail securely by denying access, including when an exception occurs. | ✓ | ✓ | ✓ | 285 |
+| **4.1.6** | [ADDED] Verify that changes to values on which access control decisions are made, are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in cryptographically secured tokens), there must be mitigating controls to alert when a user performs an action when they should no longer be able to do so, and revert the change. Note that this would be unable to mitigate information leakage.  | | ✓ | ✓ | |
 
 ## V4.2 Operation Level Access Control