Odoo ships two-factor authentication through the core auth_totp module, but it is fundamentally opt-in: each user decides for themselves whether to enable it from their preferences. For a security-conscious organisation — one pursuing SOC 2, ISO 27001, or an insurer's cyber questionnaire — "some users have 2FA turned on" is not a controllable state. An auditor asking "prove every account with access to financial and HR data uses a second factor" cannot be answered from the standard setup, and an administrator has no supported way to require enrollment, no visibility into who is covered, and no lever to block a login that skipped the second factor. This is exactly where Odoo native runs out of road, and where a bolt-on policy layer is needed.

We build a clean-room enforcement module that extends auth_totp rather than replacing it, so you keep Odoo's proven TOTP mechanism and add governance on top. At the data layer we introduce policy models (models.Model with @api.depends computed enrollment states) that bind a 2FA requirement to res.groups, letting you mandate a second factor org-wide or scope it to specific security groups — for example, require it for Accounting and Settings administrators while leaving read-only portal users optional. A configurable enrollment grace period gives users a defined window to set up their authenticator before access is hard-locked, driven by scheduled automated actions (ir.cron) that send reminder emails through the mail framework to anyone still not enrolled. Beyond authenticator-app TOTP, we implement WebAuthn / passkey (FIDO2) support so phishing-resistant hardware and platform authenticators can serve as the second factor. Enforcement is applied at the authentication controller and session layer — overriding the web login flow and the relevant RPC/session paths — so a login that bypasses 2FA when policy requires it is refused rather than merely discouraged, and step-up re-authentication can be demanded before sensitive administrative actions such as Settings changes.

Around the core enforcement we build the operational tooling security teams actually need day-to-day. A compliance dashboard (OWL/QWeb views backed by computed fields) shows enrollment status across every user, filterable by group, so the "who is covered" question has a one-screen answer. Administrators can generate and regenerate one-time-use backup recovery codes with usage tracking, and reset a specific user's 2FA for lost-device recovery — each action writing an audit entry via mail.thread so the reset is attributable and reviewable, without resorting to a full user reset. Trusted-device "remember this browser" is included with an administrator-set maximum duration and per-user revocation, and admins receive notification alerts whenever a user disables or resets their own second factor. Access is governed through ir.model.access.csv and record rules so that policy configuration and the audit trail are visible only to the roles that should see them.

Because this is a build-to-order engagement, nothing is a pre-existing download. After a short scoping call we confirm your Odoo version (17.0, 18.0, or 19.0), Community or Enterprise edition, which groups must be enforced, your grace-period and trusted-device policies, and any SSO or provisioning systems already in play. We then build against your target version, validate on a staging copy of your database through UAT, and deliver installable source with a documented rollback plan before touching production. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company enforcement, passkey/FIDO2 hardware rollout across many sites, deeper SSO or identity-provider integration, and larger user-migration volumes increase the quoted scope. You receive a fixed quote after the scoping call — the from-price is a starting point, not a firm figure.