Auth0 Hardening Guide: Tenant and M2M Settings

An Auth0 tenant is the front door for every customer login and often for every API call between services, so one weak setting or one leaked client secret exposes the whole application estate. Auth0 gives teams attack protection, token controls and machine-to-machine (M2M) authentication options, but several are opt-in, plan dependent or left in monitoring mode. This guide sets out a hardening baseline for an Auth0 tenant from the vendor's public documentation: dashboard administration, attack protection, M2M applications and client authentication, Management API tokens, API access policies, logging and the production checks. It is written for identity engineers, application security teams and auditors responsible for a customer identity (CIAM) deployment. See the Customer IAM (CIAM) Guide for the wider discipline.

Key takeaways

Attack protection must be switched to block. Bot Detection, Suspicious IP Throttling, Brute-force Protection and Breached Password Detection only log in monitoring mode until a response is configured.
Client secrets are the weakest M2M credential. Private Key JWT replaces a shared secret with an asymmetric key pair, and where it is not available secrets must be rotated on a schedule and after any incident.
The Management API token is a tenant admin key. Its default lifetime is 86,400 seconds and it cannot be revoked, so scope it tightly and keep its lifetime short.
Use API access policies to deny by default. require_client_grant for user and client access stops an application quietly gaining tokens for an API it was never meant to call.
Stream logs out of the tenant. Attack protection events such as limit_wc, limit_mu and pwd_leak and failed exchange events belong in a SIEM with retention longer than the tenant keeps them.

How identity and access work in Auth0

An Auth0 tenant is an isolated configuration holding connections (database, social and enterprise identity sources), applications (OAuth clients) and APIs (resource servers identified by an audience). Applications are typed: regular web, single-page, native and machine-to-machine. Users authenticate through Universal Login and the application receives ID, access and refresh tokens; M2M applications use the OAuth 2.0 client credentials grant (RFC 6749 section 4.4) to obtain access tokens for an API with no user involved.

Three separate planes need hardening:

Plane	Who or what authenticates	Main risk	Primary controls
Dashboard and tenant administration	Tenant members (staff)	Takeover of tenant configuration, rules and keys	Dashboard roles, MFA for tenant admins, member review
End-user authentication	Customers and workforce users	Credential stuffing, brute force, bots, breached passwords	Attack protection, MFA, refresh token rotation
Machine-to-machine and Management API	Applications, back ends, automation	Leaked client secrets, over-scoped tokens	Private Key JWT, secret rotation, client grants, API access policies, short token lifetimes

Admin roles and privileged access

Dashboard access is granted through tenant members (Settings, Tenant Members) with roles. The vendor's feature access by role documentation lists what each role can do; the Admin role carries full control of tenant settings and applications, so it is the privileged role to minimise.

Least privilege for members: give support and developer staff the narrowest dashboard role that covers their task and keep full Admin to a small platform team.
MFA for tenant admins: the production checks list MFA for tenant administrators as a required fix. Prefer a phishing-resistant method through the organisation's identity provider.
Joiner and leaver discipline: review the tenant member list at least quarterly and remove leavers the same day; tenant membership is often forgotten when someone leaves a project rather than the company.
Separate tenants per environment: keep development, staging and production in separate tenants with the environment tag set, so developer convenience settings never reach production.
Break-glass: keep at least two admins able to recover the tenant, with their access logged and tested. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

M2M applications are the non-human identities of an Auth0 deployment. Each is a client ID with a credential and a set of client grants (APIs and scopes it may request). See the Machine-to-Machine OAuth (Client Credentials) Guide for the protocol background.

Client authentication options

Method	What the client holds	Strengths	Limits
Client secret (post or basic)	Shared symmetric secret, also known to Auth0	Simple, available on every plan	Readable by dashboard admins, easy to leak in code and CI; rotation is manual
Private Key JWT	Private key; Auth0 holds the public key	No shared secret; signed assertion per request; credentials carry an expires_at	Enterprise plan; RS256, RS384 or PS256; RSA 2,048 to 4,096 bits; at most two credentials per application

Private Key JWT setup: register the public key as a credential, set expires_at, and let the key ID follow the RFC 7638 thumbprint. Once Private Key JWT is enabled the client secret is hidden. The two-credential limit allows overlap during rotation: add the new key, move the client over, then delete the old one. Reverting to client secret is done by setting client_authentication_methods to null, so restrict who can make that change.
Client secret rotation: use the Rotate action in the application's Danger Zone or the Management API with the update:client_keys scope. Allow up to 30 seconds for propagation and deploy the new secret immediately, because the old one stops working. The Cloudflare breach began with credentials that had not been rotated after an earlier incident, which is why rotation after any suspected exposure matters as much as scheduled rotation.
One M2M application per workload: never share a client ID across services; separate applications give separate client grants, separate logs and a clean revoke path.
Management API tokens: these use the audience https://{tenant}/api/v2/. The default lifetime is 86,400 seconds and the tokens cannot be revoked, so grant only the scopes the automation needs (read:users rather than everything), reduce the lifetime and fetch a fresh token per job rather than caching one for a day. Production checks also flag developer keys and ID tokens used to call the Management API; replace both.
API access policies: each API can set user and client access to allow_all, require_client_grant or deny_all. Choose require_client_grant for client access so that only applications with an explicit grant receive tokens, and use it for user access on sensitive APIs. Third-party applications always need a grant.
Refresh tokens: enable refresh token rotation for public clients. Reuse of an old refresh token invalidates the whole token family and is logged as ferrt, which is a strong theft signal.

See the API Keys vs OAuth Tokens Guide and the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.

Logging and detection

Auth0 records events in tenant logs, which are kept for a limited, plan-dependent period. The production checks recommend log streaming where more than 30 days of retention is needed. Log streams send events to a SIEM or event bus with filters and optional PII masking.

Event code	Meaning	Why it matters	ATT&CK technique
limit_wc	Blocked account (brute-force protection)	Targeted password guessing	T1110 Brute Force
limit_mu	Blocked IP address (suspicious IP throttling)	Spraying or stuffing from one source	T1110.003, T1110.004
pwd_leak, signup_pwd_leak, reset_pwd_leak	Breached password detected at login, signup or reset	Stuffed credentials from other breaches	T1110.004 Credential Stuffing
f, fu, fp	Failed login, invalid username, wrong password	Baseline for guessing and enumeration	T1110 Brute Force
s	Successful login	Correlate with prior failures and new locations	T1078 Valid Accounts
feccft	Failed exchange: client credentials for access token	M2M client using a wrong or rotated credential, or probing	T1078.004 Cloud Accounts
ferrt	Refresh token reuse detected	Likely stolen refresh token	T1528 Steal Application Access Token
fsa	Failed silent authentication	Context for session anomalies	Context only

Metrics that show the controls work:

Attack protection features in block mode rather than monitoring (target: all four).
Percentage of M2M applications using Private Key JWT, or with a client secret younger than the rotation period.
Number of tenant members with the Admin role, and percentage with MFA (target: 100%).
Maximum Management API token lifetime across applications.
Count of ferrt and feccft events per week, with each investigated.

See the SIEM Guide for detection engineering on these streams.

Hardening baseline

Tenant and application settings

The vendor's production checks are the quickest structured review of a tenant. The items below come from the required and recommended fixes lists and are worth treating as a minimum standard for every production tenant, not a one-off launch task.

Setting area	What to look for	Hardened state
Grant types	Legacy grant types still enabled on applications	Only the grants each application uses; no legacy grants
Callback and logout URLs	localhost or wildcard entries in production applications	Exact production URLs only; development URLs live in the development tenant
Token signing	HS256 signing on applications	RS256, so verifiers never hold a signing secret
Management API callers	ID tokens or developer keys used to call the Management API	M2M application with scoped client grant
Environment tag	Tenant not tagged as production	Environment tag set to production
Log retention	Reliance on tenant log retention alone	Log stream to a SIEM where more than 30 days is needed

Treat a failed check as a change request with an owner, and rerun the checks after every significant configuration release, because a single new application can reintroduce a localhost callback or a legacy grant.

Attack protection settings

Feature	Default behaviour	Recommended setting
Brute-force Protection	Threshold 10 failed attempts (range 1 to 100); Block Brute-force Logins on; Account Lockout off; returns HTTP 429 too_many_attempts	Keep blocking on, set the threshold to fit your user base, choose an unblock behaviour, keep the IP AllowList minimal
Suspicious IP Throttling	On; per-IP daily limits; HTTP 429; AllowList up to 100 entries	Keep on; if using the resource owner password grant from a back end, pass the end user's IP so the back end is not throttled or trusted
Breached Password Detection	Monitoring unless a response is set	Block the login and notify the user, at login, signup and password reset
Bot Detection	Monitoring unless a response is set	Require a challenge for suspicious traffic

Blocked accounts unblock after a successful password reset, an administrator unblock (including DELETE /user-blocks on the Management API) or after 30 days, so build the support process before turning blocking up. See the Account Lockout and Brute-Force Protection Guide and the Password Spraying and Credential Stuffing Defence Guide.

Phased rollout

Baseline: export tenant settings, the application and client grant list, API access policies and tenant members. This is your rollback copy.
Run the production checks: fix the required items first: legacy grant types, localhost callback URLs, ID tokens or developer keys used for the Management API, environment tag, MFA for tenant admins and RS256 signing.
Administration: enforce MFA for all members, cut Admin roles to the minimum and remove stale members.
Attack protection in monitoring: enable all four features, watch the events for one to two weeks to tune thresholds and AllowLists, then switch each to block. Rollback is returning a feature to monitoring.
M2M credentials: inventory M2M applications and their grants, split shared clients, move high-value clients to Private Key JWT where the plan allows, and rotate every remaining client secret. Pilot one service, check for feccft failures, then extend.
API access policies and tokens: set require_client_grant for client access on each API, shorten access token and Management API token lifetimes, and enable refresh token rotation.
Logging: configure a log stream with PII masking where required, and build alerts for limit_wc spikes, ferrt, feccft and member or setting changes.

Small versus large organisations: a start-up on a self-service plan may not have Private Key JWT, so it should rely on scheduled secret rotation, one M2M client per workload and short token lifetimes. A large enterprise with many tenants should manage configuration as code, review client grants through change control and use Private Key JWT for every back-end client.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Tenant members and roles	AC-2, AC-6	PR.AA-05	5.4, 6.8	A.8.2
Admin MFA, attack protection	IA-2, AC-7	PR.AA-01	6.3, 6.5	A.8.5
Client secrets, Private Key JWT, token lifetimes	IA-5, SC-12	PR.AA-01	5.2	A.5.17
Log streaming and review	AU-2, AU-6, SI-4	PR.PS-04	8.2, 8.11	A.8.15, A.8.16

Common misconfigurations

Attack protection left in monitoring: the dashboard shows the feature as enabled, yet nothing is blocked until a response is configured.
Client secrets in source code and CI variables: a shared secret copied into many places cannot be rotated quickly; move to Private Key JWT or a secrets manager. See the Secrets Management Guide.
Day-long Management API tokens with broad scopes: a leaked token cannot be revoked and works for 24 hours by default.
allow_all client access on internal APIs: any M2M application in the tenant can obtain a token for the API.
Back end calling the password grant without forwarding the user's IP: Suspicious IP Throttling then sees every user as the server's IP, which either blocks legitimate users or hides attackers.
No rotation after a support or vendor incident: the Okta support system breach began with a service account credential and exposed files uploaded by customers to a support system, and the Cloudflare follow-on showed the cost of credentials left unrotated afterwards. Rotate client secrets and review tenant members whenever an identity supplier reports an incident.

Practitioner checklist

Run the production checks and clear every required fix.
Enforce MFA for all tenant members and keep the Admin role to a small named group.
Move Bot Detection, Suspicious IP Throttling, Brute-force Protection and Breached Password Detection from monitoring to block.
Give every workload its own M2M application with the minimum client grants.
Use Private Key JWT where available; otherwise rotate client secrets on a schedule and after any incident.
Scope Management API tokens to the minimum scopes and cut their lifetime well below 86,400 seconds.
Set API access policies to require_client_grant for client access.
Enable refresh token rotation and alert on ferrt.
Stream logs to a SIEM with retention beyond 30 days and alert on limit_wc, limit_mu, pwd_leak and feccft.
Review tenant members, M2M applications and grants every quarter.

Auth0 Hardening Guide: Tenant, Application and Machine-to-Machine Settings