Acumatica 2FA and Password Policies

Two-factor authentication and password policy in Acumatica are configured entirely from the user-security screens — there is no code to write for the common cases. The work is in choosing sensible settings, understanding how they interact with SSO and the mobile app, and communicating the trade-offs to users who will feel every one of them at login time.

Where the settings live

Password complexity, expiration, and lockout are set per user type on User Types (EP202500) and enforced through the security preferences on Security Preferences (SM201060). Two-factor authentication is enabled per user on the Users (SM201010) screen and globally gated by the identity settings. The important mental model: a user type carries a password policy, every user is assigned a type, and the strictest applicable policy wins. If you tighten complexity globally but a user type overrides it, the override is what the user experiences.

Password complexity and expiration

On Security Preferences you control minimum length, whether mixed case and digits are required, how many previous passwords are remembered (to block reuse), and the maximum age before a forced change. The two settings people get wrong are expiration and history depth. Aggressive expiration — 30 days — reliably produces Password1!, Password2!, Password3!, because users optimise for what they can remember under pressure. Current guidance (NIST 800-63B and most auditors that have caught up to it) is to drop scheduled expiration entirely and rely on length plus breach detection instead. If your compliance regime still mandates rotation, pair a longer interval with a deep password history so the incremental-digit trick stops working.

Enabling two-factor authentication

Acumatica's built-in 2FA is TOTP-based: the user pairs an authenticator app (Google Authenticator, Microsoft Authenticator, Authy) by scanning a QR code, and thereafter enters a rotating six-digit code after their password. You enable it per user on the Users screen by setting the Two-Factor Authentication option, and you can require it for a whole group by making it part of the user type or by scripting the flag across users. The first login after enabling walks the user through pairing; keep in mind the code is time-based, so the server and the user's device clock both need to be reasonably in sync.

Account lockout policy

Lockout is your defence against online password guessing. On the security settings you set the number of failed attempts before an account locks and how long the lock lasts. A common balance is a handful of attempts (enough to survive a fat-fingered password) with a lockout measured in minutes rather than a permanent lock that needs an admin to clear. A permanent lock is more secure on paper but converts every mistyped password into a help-desk call, and help desks under load are themselves a social-engineering surface. Temporary lockouts of increasing duration give you most of the protection with far less operational cost.

SSO and external identity providers

The moment you integrate an external identity provider — Azure AD / Entra ID, Google, or any OpenID Connect source — the picture changes. Password policy and 2FA then live with the identity provider, not with Acumatica. Configuring Acumatica's local password complexity is pointless for users who authenticate through Entra ID, because they never present a local password. Decide where authentication actually happens and put your controls there. A frequent misconfiguration is enforcing strict local 2FA and IdP 2FA, double-prompting users for no additional security.

Local accounts (Acumatica-managed password)
  Security Preferences: min length 12+, disable scheduled expiration
  Password history: 5+ remembered
  Lockout: 5 attempts, 15-minute temporary lock
  Users: enable TOTP 2FA for admin + finance roles

Federated accounts (Entra ID / OIDC)
  Enforce password + MFA at the identity provider
  Do NOT double-enforce local 2FA
  Local password policy is inert — do not rely on it

Rolling it out without a flood of tickets

Sequence matters. Turn on password complexity first and let it take effect on the next password change rather than forcing an immediate reset. Introduce 2FA to a pilot group — typically administrators and finance, the highest-value accounts — before the whole tenant. Publish a one-page guide with screenshots of the pairing flow, and make sure the help desk knows how to reset a lost authenticator before the rollout, not after. Every security control here trades user friction for reduced risk; the job is to spend that friction where the risk is highest and skip it where an external IdP already covers you.

Wrapping up

None of this needs custom code — it needs deliberate choices. Favour length over rotation, prefer temporary lockouts over permanent ones, require TOTP 2FA on the accounts that can move money, and if you run SSO, enforce at the identity provider and stop configuring inert local policy. Get the recovery runbook written before you flip the switch, and the rollout stays quiet.