Ad
 
Learn More

Effective TFA policy is the Important line in Directus 12.5

Directus v12.5.0 is flagged Important as a breaking change. The partner-break line is two-factor enforcement now resolving from effective policies (#28176) plus stricter ip_access validation, not the Preview Base URL setting.

Written by Watch Changelog Team

•3 min read

Effective TFA policy is the Important line in Directus 12.5

So Directus put v12.5.0 on the feed, dated October 7, 2026. We flagged it Important as a breaking change. Recency wants the calm opener: a Preview Base URL project setting, header buttons to switch a batch of Flows on or off, linked images in the WYSIWYG editor, an opt-in Redis hash option for faster cache clears. Fine. Those are the lines people paste into a CMS channel when they skim a release.

The line that matters, to the best of my understanding, sits at the top of the Potential Breaking Changes block: TFA enforcement now uses effective permissions (#28176). At login, Directus now works out the enforce_tfa claim from the user's effective policies. That includes policies inherited through roles, policies attached directly to the user, and ip_access filtering against the request IP. The claim is recalculated on session refresh too. Users who already set up two-factor skip the check, and so do share sessions. The PR title says the old check did not use effective permissions, so some accounts that a policy said must use two-factor were not being asked to.

That is the partner ticket shape. Someone already thought "we turned on Require 2FA for the editors policy, we're covered." Then the upgrade lands, and the next login or token refresh drops an account that never enrolled into two-factor setup. For a person, that is a setup prompt and a small surprise. For a shared login that an agency, a partner, or an internal tool signs in with by email and password, it is a ticket about a login that worked yesterday. Static tokens don't go through login, so check how each integration actually authenticates before you assume it is fine.

The second line in the same block is quieter and meaner. The ip-matching dependency is gone (#28243), and policy ip_access and IMPORT_IP_DENY_LIST values are now validated strictly. A subnet with a malformed prefix, like 10.0.0.0/ 24 or 10.0.0.0/+24, is no longer accepted. The release notes say an existing policy that already stores such a value will fail every request for users with that policy. Nobody gets a prompt. They just stop working.

What operators should check first is not the Preview Base URL setting. It is the policy table. List the policies that require two-factor, then list the users who reach one of them through a role, a direct assignment, or an IP-scoped policy and have not set up TFA yet. Those are the accounts that will hit setup after the upgrade. Then scan every ip_access value and your IMPORT_IP_DENY_LIST env for a space or a plus sign inside a CIDR prefix, and fix them before you deploy, not after. While you are in the upgrade notes: CACHE_SCHEMA_MAX_ITERATIONS is removed, CACHE_SCHEMA_SYNC_TIMEOUT now also limits the schema build and defaults to 60000 ms, /server/license drops downgrade_reason in favor of invalid_reason, and @directus/sdk 27 retypes DirectusNotification.id as a number.

The same release also fixes a GraphQL query whose __proto__ field alias could write a property onto Object.prototype (#28211), and carries a dependency CVE train (undici, axios, nodemailer, basic-ftp, proxy-addr, dompurify and others). Those matter for scanners and hardening. They are not the hero. The hero is that two-factor enforcement now follows the policies you actually assigned.

I keep almost filing Directus under "CMS minor, ignore until the SDK major bites." Kind of the wrong habit when you sell into teams that run Directus as the admin backend for partners and assume the 2FA checkbox already meant what it said. Tracking product change here means reading past the feature list and asking which line changes a partner ticket. Let's say the talking point is not "12.5 adds a Preview Base URL." It is two-factor enforcement now resolving from effective policies, plus strict ip_access parsing that can lock out a policy with a sloppy subnet, then yes mention the prototype fix and the CVE bumps. We pull it into a uniform entry shape at /sources/directus-cms.updates. Same JSON as everything else. Recency still wants the Preview Base URL. Recency is not the TFA policy.

Official notes: Directus v12.5.0. Fix PR: Fix TFA enforcement to use effective permissions (#28176).