SecurityCustomer identity

Auth0 moved the Rules and Hooks deadline: Hooks stop on 30 April 2027, Rules on 31 January 2028

Auth0 has dropped the single 18 November 2026 end-of-life date for Rules and Hooks. Hooks now stop after 30 April 2027 and Rules after 31 January 2028, so most teams should move their Hooks to Actions first.

Cohash Security Practice October 2026 14 min read 6 chapters 3-question check
part 15 of 25 · Platform releases, explained from scratch
Coderead-only Old: 18 Nov2026 Hooks stop Rules stop Nov 2024 Jan 2028

the ideaTwo dates now, not one. Hooks go first, Rules nine months later.

after reading, you can
  • Tell your team which date applies to them now, and why the Hooks still in your tenant need to move first
  • Plan a cut-over that starts from the last rule, so someone can switch the old rule back on if tokens break
  • Spot the Rules patterns that have no direct Actions equivalent before they hold up your migration

If your Auth0 tenant still runs RulesdefinitionThe JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last. or HooksdefinitionOlder Auth0 scripts for moments outside login. Someone might have used one to stamp machine-to-machine tokens or check sign-ups, and then forgotten about it., the 18 November 2026 cut-off you were planning around is gone. Auth0's docs now say Hooks stop running after 30 April 2027 and Rules after 31 January 2028. Use the extra months to migrate properly, not to wait.

in plain wordsDeadline moved: plan Hooks first

Auth0 gave you more time, but Hooks run out nine months before Rules do

Auth0 handles sign-in for your apps and customers. For years, the way to add your own logic to that sign-in, like stamping a user's role into their token or blocking a risky login, was to write a small script called a rule. Scripts that ran at other moments, such as sign-up or a password change, were called hooks. Auth0 replaced both with Actions and has been retiring the old ones in stages. Until recently its docs said both would stop on 18 November 2026. Now they say Hooks stop after 30 April 2027 and Rules after 31 January 2028. Whatever is still a rule or a hook after those dates stops running, and whatever it did for your logins stops with it.

think of it like this

Picture an office where the old badge readers are being switched off. Facilities has moved the date twice. Now the side doors stop reading old cards in spring and the front door the winter after, so anyone using a side door needs a new card first.

who should care
  • Tenants created before 16 Oct 2023
  • Apps that read roles from Auth0 tokens
  • Anyone using the Authorization Extension
  • Owners of M2M or sign-up Hooks
  • Auditors who check login controls
chapter 01

Why the new dates matter to you

30 Apr 2027Hooks stop running and are removed after this date
31 Jan 2028Rules stop running and are removed after this date
18 Nov 2026The single end-of-life date Auth0's docs gave until recently
Nov 2024Rules and Hooks code became read-only

A rule that adds a role to a token is a security control. When it stops running, the app gets a token without the role. Depending on how the app was written, that user either can't do their job or gets in with the wrong permissions. A hook that checks sign-ups or stamps machine-to-machine tokens fails the same way, and you only find out when something downstream breaks.

The extension helps, but only if you spend it. You still can't fix a bug in an old rule, because the code is frozen. And this is the second time the plan has changed. Auth0's original plan in 2023 was to remove both on 18 November 2024. That became read-only modedefinitionWhat old Rules and Hooks have been stuck in since 18 November 2024. They still run and you can still switch them off. Nobody can change a line of their code. instead, then an 18 November 2026 end of life, and now two separate dates. Don't budget on a third move.

The split matters most for teams that planned one project for both. Hooks are usually fewer and simpler, but people forget them because they don't run at login. They handle things like client credentials grants for your APIs and phone messages for MFA. Move those first and give the bigger Rules pipeline the rest of the runway.

what changesHow the old pipeline gives way to ActionsRules run first, then any Actions bound to the same trigger. That order is what lets you migrate one piece at a time.
  1. 01 A user signs in

    Auth0 checks the password, social login or enterprise connection as usual. Nothing about this step changes.

  2. 02 Active Rules run in order

    Each rule gets the user and the login context, adds a claim or blocks the login, then hands over to the next one. Order matters, so write it down before you touch anything.

  3. 03 Post-login Actions run next

    When the last active rule finishes, Auth0 runs the Actions you've bound to post-login. Switch a rule off and its Action picks up the work.

  4. 04 Tokens go to the app

    Your app reads the claims and gets on with it. If they match what the old rules used to produce, nobody downstream notices the change.

  5. 05 After the dates, only Actions

    Hooks go after 30 April 2027 and Rules after 31 January 2028. Anything you haven't converted by then just stops running, and whatever it added to the login is gone.

For engineers: Auth0 says Post-Login Actions run after active Rules, and recommends converting from the end of the pipeline backwards. The rules that run early stay in place while the later logic moves to Actions, so nothing reads a claim before the code that writes it is in place.

chapter 02

What changed, and what stays the same

side by sideHow Auth0's plan for Rules and Hooks changed
The old plan
  • One date for both: 18 November 2026
  • One project for both
  • Too little time for a careful job
  • Code read-only since November 2024
The plan now
  • Hooks stop after 30 April 2027
  • Rules stop after 31 January 2028
  • Two cut-overs, Hooks first
  • Code still read-only, still runs

The Auth0 changes that touch this migration

changedHooks end of life moves to 30 April 2027

Hooks keep running until then. After that date Auth0 says they stop running and are removed. Every Hook type needs an Action on the matching trigger before then.

changedRules end of life moves to 31 January 2028

You've got until then for the login pipeline. After that Auth0 stops and removes every rule, so each one needs a post-login Action waiting for it.

deprecatedRules and Hooks code is read-only

Since 18 November 2024 nobody can edit their code, whether in the Dashboard, the Management API, the Auth0 CLI, Deploy CLI, Terraform or Agent Skills. You can still enable, disable and change secrets.

removedNo Rules or Hooks in new tenants

Tenants created on or after 16 October 2023 never got them. A new development tenant can't host a copy of an old rule to test against.

newRule migration tooling in the Dashboard

Open Auth Pipeline, then Rules, and each rule has a Migrate to Action option that walks you through common patterns. Nothing goes live until you activate the new Action yourself.

deprecatedLegacy custom DB user import ends 20 January 2027

A separate Auth0 deadline. Custom database connections that import users get a full import instead of the old partial-import edge cases.

deprecatedProfile size migration period ends 4 March 2027

Tenants flagged for profiles near or over 10KB lose their migration period, and Auth0 enforces the limit, plus an extra allowance, some time after. Anything a rule writes into app_metadata counts toward that size.

The read-only rule is the one that bites in practice. If a rule has a bug today, the only fix is to switch it off and replace it with an Action. That also catches CI/CD pipelines: Auth0 says editing their code is unsupported and tells you to make sure deploys don't attempt it, so check your Deploy CLI or Terraform config before the next release goes out.

Operators on Auth0's community forum point to two traps the docs don't stress. Some tenants have rules they never wrote by hand, such as the one the Authorization Extension generates, and people have had to rewrite that one as an Action themselves. One user found that after switching the tenant to Node 22, a package their extension's Hooks needed was missing from the legacy sandbox. Auth0 says that setting applies to Rules, Hooks, custom database scripts and custom social connections at once, so a runtime change can break frozen code you can't patch.

tableHook types and the Actions trigger each one moves to. Hooks run out first, so this is usually where you start.
Hook typeActions triggerStops afterWatch out for
Client Credentials ExchangeM2M / Client-Credentials30 Apr 2027Extra claims your APIs expect in M2M tokens
Pre-User-RegistrationPre User Registration30 Apr 2027Sign-up checks that block or tag new users
Post-User-RegistrationPost User Registration30 Apr 2027Calls to your CRM or welcome-email service
Post-Change-PasswordPost Change Password30 Apr 2027Notifications and session clean-up
Send Phone MessageSend Phone Message30 Apr 2027Your own SMS provider for MFA codes
Every RuleLogin / Post Login31 Jan 2028Order, redirects, Management API calls

How the Rules and Hooks retirement has moved

  1. May 2023
    Deprecation announced

    The first plan: remove both in November 2024.

  2. 16 Oct 2023
    Gone from new tenants

    New tenants never get Rules or Hooks.

  3. 18 Nov 2024
    Read-only instead of removal

    Auth0 backed off removing them. Existing Rules and Hooks kept running, but nobody could edit the code.

  4. 22 Sep 2026
    Docs still say 18 Nov 2026

    The archived Hooks page still gives one date.

  5. 30 Apr 2027
    Hooks stop running

    Hooks are removed after this date.

  6. 31 Jan 2028
    Rules stop running

    Rules are removed after this date.

chapter 03

How to move Rules and Hooks to Actions

before

Before: a chain of Rules with shared globals

Rules run one after another, share global configuration, and call the Management API with the token Auth0 hands every rule. Hooks sit on other events.

Before: a chain of Rules with shared globals Rules run one after another, share global configuration, and call the Management API with the token Auth0 hands every rule. Hooks sit on other events. 01 · LOGIN 02 · RULES PIPELINE 03 · SHARED updates metadata reads secrets Universal Login password, social, SSO Rule 1: enrich profile Rule 2: add role claims Rule 3: MFA or redirect Global configuration every rule sees every secret Management API built-in auth0 token © Cohash · cohash.com
01 · LOGIN02 · RULES PIPELINE03 · SHARED Universal Login: password, social, SSO Universal Login password, social, SSO Rule 1: enrich profile Rule 1:enrichprofile Rule 2: add role claims Rule 2: addrole claims Rule 3: MFA or redirect Rule 3: MFAor redirect Global configuration: every rule sees every secret Globalconfiguration every rule seesevery secret Management API: built-in auth0 token Management API built-in auth0token updates metadata reads secrets © Cohash · cohash.com
after

After: each Action keeps its own secrets

Each Action sits on a trigger, keeps only its own secrets and npm dependencies, and gets a Management API token from a machine-to-machine app you register, if it needs one at all.

After: each Action keeps its own secrets Each Action sits on a trigger, keeps only its own secrets and npm dependencies, and gets a Management API token from a machine-to-machine app you register, if it needs one at all. 01 · LOGIN 02 · POST-LOGIN TRIGGER 03 · PER ACTION own secrets only if needed Universal Login unchanged for users Action: enrich profile Action: role claims Action: MFA or redirect Action secrets scoped to one Action M2M app token for Management API © Cohash · cohash.com
01 · LOGIN02 · POST-LOGIN TRIGGER03 · PER ACTION Universal Login: unchanged for users Universal Login unchanged for users Action: enrich profile Action:enrichprofile Action: role claims Action: roleclaims Action: MFA or redirect Action: MFAor redirect Action secrets: scoped to one Action Action secrets scoped to oneAction M2M app: token for Management API M2M app token forManagement API own secrets only if needed © Cohash · cohash.com

The migration path, from inventory to switch-off

  1. 01
    List every Rule and Hook

    Export them with the Deploy CLI or the Management API into source control, including disabled ones. Write down who owns each one and which apps read what it produces. Rules a past extension created count too.

  2. 02
    Sort keep, merge or delete

    Plenty of old rules do nothing useful any more. Disable a suspect one in a test tenant first and watch what changes. The fewer you carry over, the shorter the cut-over.

  3. 03
    Do the Hooks first

    Hooks run out first, on 30 April 2027, so start there. Map each one to its trigger with the table above, and remember an Action can't hold on to data like an access token between runs.

  4. 04
    Rewrite each rule as a post-login Action

    Replace callback() with return or api.access.deny(), context.idToken with api.idToken.setCustomClaim(), and context.multifactor with api.multifactor.enable(). Move secrets from global configuration into that Action's own secrets.

  5. 05
    Capture tokens before and after

    In a staging tenant, log in as test users from each connection and app and keep the ID and access tokens. After every change, compare the claims. Same claims means the app can't tell anything moved.

  6. 06
    Cut over from the last rule backwards

    Deploy the Action, bind it to the trigger and disable the matching rule, one straight after the other. Auth0 warns there can be a moment when both run or neither does, so pick a quiet hour.

  7. 07
    Keep the rollback ready

    If tokens look wrong, re-enable the rule and take the Action out of the flow. That's the rollback Auth0 documents, and it only works while Rules still run. After 31 January 2028 there's nothing to roll back to.

  8. 08
    Switch off what's left

    Once a rule has been disabled for a full release cycle with no complaints, delete it. Make sure your Deploy CLI or Terraform config no longer tries to manage it.

Two gaps are the likeliest to need a real redesign. Rules that read an upstream social or enterprise provider's token from user.identities have no direct equivalent in post-login Actions, so the feature built on top of them needs a new design. Rules that call the Management API on every login are the other one. In Actions every call needs its own token request first, and Auth0 warns that Management API calls on a busy login path can cause failed logins at peak times.

Metadata updates get easier. A rule had to call the Management API to save app_metadata, while an Action can set several metadata changes and Auth0 sends them in one call. That's also a chance to stop writing data into user profiles that keeps growing them toward the new 10KB limit.

chapter 04

What to do now, by role

What to do now, by who you are

Business ownerthis month
  • Ask whoever runs your Auth0 tenant if it still has active Rules or Hooks, and how many.
  • Ask for a plan with real dates in it. You want Hooks finished well before 30 April 2027, and Rules before 31 January 2028.
  • Put the migration into the next two quarters' budget instead of leaving it for late 2027.
Identity and IT teamthis quarter
  • Export every Rule and Hook into source control and give each an owner.
  • Check that CI/CD deploys don't try to change Rule or Hook code. Auth0 no longer supports it.
  • Don't switch the tenant runtime without testing legacy Hooks and Rules first.
  • Check the other Auth0 deadlines too. The custom DB import change lands on 20 January 2027 and the profile size migration period ends on 4 March 2027.
Developersthis quarter
  • Do the Hooks first, since they stop sooner. Use the mapping table to pick each one's trigger.
  • Rewrite rules as post-login Actions, starting with the last one. One Action per rule makes it easy to switch back.
  • Replace the global auth0 object with an M2M app.
  • Save the tokens before each change and again after it. If the claims differ, you've found the bug before users do.
Security and auditbefore each cut-over
  • Find the rules that enforce something, like MFA, blocking a login or adding role claims. Those are the ones auditors will ask about.
  • Confirm each control works in Actions with a test login before its rule goes off.
  • Watch tenant logs after every cut-over for failed logins and denied access.
chapter 05

Harden the login flow while you're in there

Fixes that make the next change easier

  1. 01
    Keep Actions in source control

    Deploy them through the Deploy CLI or Terraform, with code review. A frozen rule nobody could edit is how a lot of tenants got here.

  2. 02
    Scope secrets to one Action

    Rules shared one global configuration, so every rule could read every secret. Give each Action only the secrets it needs and rotate the ones the old rules used.

  3. 03
    Take the Management API off the login path

    Where you can, move profile syncs and role lookups to the token, to metadata or to a background job. Every call on login is a call that can hit a rate limit at peak.

  4. 04
    Test logins on every deploy

    Keep the captured test tokens and run them against staging on each change. It's cheap and it catches a missing claim before your users do.

If a cut-over goes wrong

The usual failure is a missing or wrong claim after a rule goes off: users locked out, or let in with the wrong role. Work through these phases in order, and fix the Action before you try the cut-over again.

  1. 01Stop the damagefirst 15 minutes
    • Switch the rule you just disabled back on and pull the new Action from the trigger. Logins go back to how they were.
    • If the bad tokens gave too much access, revoke refresh tokens for affected users.
    • Warn the support desk. Users will call about failed logins or missing features, and someone there should know why.
  2. 02Find the causefirst day
    • Diff the claims in the captured tokens against tokens issued during the failure.
    • Read the Action's execution logs while you still have them. Auth0 keeps them for 10 days, and the tenant logs show which logins were denied.
    • Check for order problems: a later rule that read a value the Action now sets too late.
  3. 03Fix and retestthis week
    • Fix the Action in staging, then rerun the full set of test logins.
    • Check every app that reads the claim. Mobile apps can hold on to old tokens for a while.
  4. 04Report and learnafter the fix
    • If users got access they shouldn't have, record it as a security incident and follow your notice duties.
    • Add the failed case to your test logins so it can't come back unnoticed.
chapter 06

What this looks like in real setups

Three typical Auth0 tenants

01 M2M token 02 Old Hook stops 30 Apr 2027 03 M2M Action same claim 04 Internal API
scenario 01Medium risk
A SaaS start-up with three Rules and one Hook
the setup
A small product team set up Auth0 in 2021. Three rules add roles and an org ID to tokens, and a Client Credentials Hook adds a scope for an internal API.
what happens
They'd planned a two-week push before 18 November 2026, and now it's tempting to shelve it. If the Hook is still there after 30 April 2027, the internal API starts rejecting service tokens and someone gets paged.
what to do
Move the Hook first, now, while the team remembers it. Convert the three rules in one sprint and keep the old ones disabled for a release before deleting.
01 User login 02 Generatedrule frozen, no owner 03 Post-loginAction 04 Role claims same as before
scenario 02High risk
A B2B platform using the Authorization Extension
the setup
A business software vendor manages groups and roles through Auth0's Authorization Extension, which wrote its own rule into the tenant years ago. Nobody on the current team has read it.
what happens
Nobody owns the rule and nobody can edit it. Leave it until Rules stop after 31 January 2028 and tokens lose their group and role claims. Every customer's permissions break the same day.
what to do
Treat the generated rule like any other: read it, rewrite it as a post-login Action, and compare tokens for users in each group. Plan the longer-term home for authorization while you're at it.
01 Rule 20 toAction 02 Token diff 03 Rule 19 toAction 04 Rulesswitched off
scenario 03High risk
An enterprise tenant with a long Rules pipeline
the setup
A large retailer runs about twenty rules: profile enrichment, a fraud API call, account linking, MFA step-up and a redirect for terms acceptance. Some call the Management API on every login.
what happens
A big-bang cut-over leaves a moment where both or neither run, and peak-hour Management API calls start failing logins in Actions. The redirect rule needs a full redesign.
what to do
Cut over from the last rule backwards, one at a time, in quiet hours. Take Management API calls off the login path and rebuild the redirect with Actions' redirect functions.

We plan and run Auth0 migrations, including this one, and compare tokens before and after every step so you can see nothing changed for users. Our Auth0 page shows what we do. If you'd rather keep the work in-house, you can hire Auth0 engineers to join your team, or start with a short identity assessment that counts what your tenant still runs.

key takeaways

What to take from this

  1. 01

    The November cut-off is gone. Hooks now stop at the end of April 2027 and Rules at the end of January 2028, so plan two cut-overs.

  2. 02

    Move Hooks first. They're fewer, but they sit on M2M tokens, sign-ups and SMS paths people forget.

  3. 03

    Convert rules starting from the last one and compare token claims each time. If something breaks, switch the old rule back on.

  4. 04

    Plan around the gaps: no built-in Management API token, no connectionOptions, no upstream tokens, redirects rebuilt.

  5. 05

    The code is frozen. Use the extra months to migrate, because there's nothing to fix in place.

platforms in this noteAuth0 →
fact-checked October 2026 against vendor and official documentation · where to go next
  1. How Cohash delivers Auth0: scope, roles and architecture
  2. Hire vetted Auth0 engineers
  3. Customer identity
  4. Book a 30-minute working session with a senior engineer
01When do Auth0 Rules and Hooks stop working?

Hooks stop running after 30 April 2027 and Rules after 31 January 2028, and Auth0 removes them then. Until then they keep running as they are. You just can't change their code, which has been frozen since November 2024.

02Did Auth0 extend the Rules and Hooks deadline?

Yes. Until recently Auth0's docs gave one cut-off for both, in November 2026. Hooks now run until the end of April 2027 and Rules until the end of January 2028. It isn't the first time the plan has moved, which is exactly why you shouldn't count on another.

03What happens if we miss the date?

The code stops running and Auth0 removes it, so whatever it did stops happening. Claims it used to add go missing, checks it used to make get skipped, and Hooks on M2M tokens or sign-ups stop. Depending on the app, users get locked out or get the wrong access, and there's no old rule left to switch back on.

04Can we still edit a rule to fix a bug?

No. Since 18 November 2024 you can't edit Rules or Hooks code in the Dashboard, the Management API, the Auth0 CLI, Deploy CLI or Terraform. You can still turn them on or off and change their configuration values and secrets. To fix a bug, rewrite the logic as an Action and switch the rule off.

05Is there a tool that converts Rules to Actions?

Yes, partly. In the Auth0 Dashboard under Auth Pipeline, Rules, each rule has a Migrate to Action option with guidance and fixes for common patterns. You still review the code, test it in staging and choose when to activate it. Auth0 says to migrate in reverse order, starting with the last rule.

06Do Actions do everything Rules did?

Most of it, but check the gaps first. Actions don't get a built-in Management API token or the global auth0 object. Post-login Actions can't read context.connectionOptions or upstream identity provider tokens through user.identities, and they can't delete standard claims. Each run also has to finish within 20 seconds.

07Our tenant is new. Do we need to do anything?

Probably not for this. Tenants created on or after 16 October 2023 never had Rules or Hooks, so any extensibility you add uses Actions. Do check the other Auth0 dates, like the custom database import change on 20 January 2027.

up next in this track

Keep the thread going.

What shipped, what changed underneath, and what it means for your upgrade.

  1. 01HashiCorp Vault 2.2 explained: TPM login, post-quantum PKI and the October fixes
  2. 02Upgrading to SailPoint IdentityIQ 9.0: what breaks and what to fix first
  3. 03Terraform 1.17 explained: what's new, who it touches and how we'd upgrade
  4. 04BeyondTrust Remote Support zero-day: patch it, then check who got in
  5. 05Patch PHP and Node.js this week: what broke and who's exposed
  6. 06OpenShift support dates through 2027: which clusters run out first and how to plan the upgrades
  7. 07Oracle's October security patches: what to fix first in EBS, PeopleSoft and Access Manager
  8. 08Oracle Java drops four root certificates over eMudhra: patch, then test what breaks
  9. 09Delinea Secret Server auth bypass: why the FIDO2 hotfix isn't enough
  10. 10IBM Verify Access flaws let attackers run code without a login: patch to 11.0.3.2
  11. 11Foundry Workflows retire on December 1. We'd start moving yours to Agent Framework now
  12. 12Vertex AI is retiring text-embedding-005 and three other embedding models: how to re-embed before search breaks
  13. 13dbt drops v1.3 to v1.7 from its platform on January 31, 2027: get pinned jobs onto a release track before they're deleted
  14. 14Brotli CVE-2026-111497 is now on CISA's exploited list, and you probably run more copies than you think
  15. 15Auth0 moved the Rules and Hooks deadline: Hooks stop on 30 April 2027, Rules on 31 January 2028
  16. 16Still on Okta Classic Engine? Three features stop working on March 5, 2027, and two of them block the upgrade
  17. 17Patched GitLab, still exposed: the CI regex bug CISA lists as exploited, and the Ruby step people miss
  18. 18Patched Ivanti Connect Secure in October? Two more exploited bugs, and the AD cleanup
  19. 19Patch roundup, week of Oct 26: upgrade Secret Server today, then work down the list
  20. 20UiPath 2023.10 support has run out and 2024.10 is next. What we'd upgrade first
  21. 21Password Safe 24.3 runs out of support in December, and 26.3 is still one upgrade away
  22. 22Upgrade Entra Connect Sync before April 2027 and move users off Microsoft's SMS codes
  23. 23Chrome drops XSLT on 17 November. What breaks in InterSystems, and the fix for your version
  24. 24Agent Builder, Evals and saved prompts shut on 30 November. Here's what to pull out first
  25. 25BeyondTrust Remote Support and PRA 24.3 lose support in November, and there's no one-step upgrade
all learning tracks →
First notice UpgradePreview Upgradeproduction Features off Aug 2026 Mar 2027
Security · 14 minStill on Okta Classic Engine? Three features stop working on March 5, 2027, and two of them block the upgrade

Three Classic features stop on March 5, 2027. Upgrade Preview first, then test.

read next
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it