---
title: "Breaking: #97265 - Simplified access mode system"
manual: "TYPO3 Core Changelog"
version: "main"
permalink: "https://docs.typo3.org/permalink/changelog:breaking-97265"
source: "Changelog/12.0/Breaking-97265-SimplifiedAccessModeSystem.rst"
typo3-version: "12.0"
typo3-major: 12
type: "breaking"
issue: 97265
forge: "https://forge.typo3.org/issues/97265"
tags: ["Backend", "Database", "LocalConfiguration", "PHP-API", "TCA", "PartiallyScanned", "ext:core"]
rendered: "2026-10-01T16:39:42+00:00"
---

# Breaking: #97265 - Simplified access mode system {#breaking-97265}

See [forge#97265](https://forge.typo3.org/issues/97265)

## Description {#description}

In preparation of a deployable backend access rights system based on
configuration files, some rarely used details of the permission system
have been streamlined and simplified:

-   The global configuration option `TYPO3_CONF_VARS['BE']['explicitADmode']`
    has been removed and is not evaluated anymore.
-   The only valid value for TCA config option `authMode` on `'type' => 'select'`
    fields is now `explicitAllow`. The values `explicitDeny` and `individual`
    are invalid and no longer evaluated.
-   With removal of `authMode' => 'individual'` for TCA select fields, the sixth
    `items` option is obsolete and removed. The values `EXPL_ALLOW` and
    `EXPL_DENY` are without any effect.
-   Handling of TCA config option `authMode_enforce` has been removed.
-   The fourth tuple of `be_groups` field `explicit_allowdeny` that was
    previously set to either `ALLOW` or `DENY` is removed.
-   The fourth argument on `BackendUserAuthentication->checkAuthMode()` has
    been removed.

## Impact {#impact}

Using any of the above removed options will trigger a PHP `E_USER_DEPRECATED` error.
Using `explicitDeny` and `individual` as value for TCA config option
`authMode` is no longer supported by the system and may need manual
adaptions. Accessing `$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`
may lead to a PHP warning level error.

## Affected Installations {#affected-installations}

-   Instances with extensions using `$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']`.
    The extension scanner will typically find affected instances.
-   Instances with TCA select fields using `'authMode' => 'explicitDeny'`.
-   Instances with TCA select fields using `'authMode' => 'individual'` and select
    items being set to `EXPL_ALLOW` or `EXPL_DENY`. This is a very rarely used
    option and it's unlikely modern extensions use this in practice: There is not a single
    extension in the TER using this option combination and it's unlikely to be used in
    custom extensions, either.
-   Instances manually dealing with the `explicit_allowdeny` of table `be_groups`
    may be affected if they expect the fourth field being set to `ALLOW` or `DENY`.
    This is unlikely since the Core provides an API for this field using
    `BackendUserAuthentication->checkAuthMode()`.
-   Instances calling `BackendUserAuthentication->checkAuthMode()` with four instead of
    three arguments. The extension scanner will find usages as weak match.
-   Instances using `authMode_enforce` for `'type' => 'select'` fields.

## Migration {#migration}

The majority of instances does not need to take care of anything. The values of the database
field `explicit_allowdeny` for table `be_groups` are updated with an upgrade wizard.
This should be executed. The following parts of this section outline options for rare cases
if specific seldom used options are used.

### Accessing explicitADmode {#accessing-explicitadmode}

The handling of `$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode']` has been changed as
if it is always set to `explicitAllow`. Extensions should not assume this global array
key being set anymore since TYPO3 Core v12. Extensions that need to stay compatible with v11
and v12 should fall back: `$GLOBALS['TYPO3_CONF_VARS']['BE']['explicitADmode'] ?? 'explicitAllow'`.

### Using authMode_enforce='strict' {#using-authmode-enforce-strict}

Extensions with select fields using `authMode` previously had different handling
if `authMode_enforce => 'strict'` has been set: Let's say an editor accesses a record
with an `authMode` field being set to a value it has no access to. With `authMode_enforce`
*not* being set to `strict`, the editor was still able to edit the record and set the value
to something it had access to. With `authMode_enforce` being set to `strict`, the editor
was not allowed to access the record. This has been streamlined: The backend interface no longer
renders those records for the editor and an "access denied" message is rendered instead. To
prevent this, a group this editor is member of needs to be adapted to allow access to this
particular value in the "Explicitly allow field values" (`explicit_allowdeny`) field.

### Using authMode='explicitDeny' {#using-authmode-explicitdeny}

The "deny list" approach for single field values has been removed, the only allowed option
for `authMode` is `explicitAllow`. Extensions using config value `explicitDeny`
should be adapted to switch to `explicitAllow` instead. The upgrade wizard
"Migrate backend groups "explicit_allowdeny" field to simplified format." that transfers
existing `be_groups` rows to the new format *drops* any `DENY` fields and instructs
admins to set new access rights of affected backend groups.

### Using authMode='individual' {#using-authmode-individual}

Handling of `authMode` being set to `individual` has been fully dropped. There is
no Core-provided alternative. This has been an obscure setting since ever and there is no
direct migration. Extension that rely on this handling need to find a substitution based on
Core hooks, Core events or other existing Core API functionality.