A build-to-order Odoo module that turns two-factor authentication from an optional user preference into an enforced org-wide policy — mandating TOTP or passkeys per security group, with enrollment grace periods, admin-managed backup codes, and trusted-device controls. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that turns two-factor authentication from an optional user preference into an enforced org-wide policy — mandating TOTP or passkeys per security group, with enrollment grace periods, admin-managed backup codes, and trusted-device controls. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
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.
Group-scoped enforcement policies binding a mandatory-2FA flag to `res.groups`, so you require a second factor org-wide or per security group (e.g. Accounting, Settings admins) while leaving chosen groups optional
Extends Odoo core `auth_totp` rather than replacing it — the proven TOTP secret and verification stay intact; the module adds the governance and enforcement layer above it
Configurable enrollment grace period with a defined countdown per user, after which access is hard-locked until a second factor is set up
WebAuthn / passkey (FIDO2) second-factor support for platform and hardware authenticators, offered alongside authenticator-app TOTP
Admin-managed backup recovery codes with one-time-use tracking, per-user regeneration, and a used/remaining count surfaced in the UI
Trusted-device 'remember this browser' with an administrator-set maximum duration and per-user, per-device revocation
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 2–4 weeks from confirmed scope. Pricing starts from $249 (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.
Responsible for SOC 2 or ISO 27001 controls and needs to guarantee — and evidence — that every account with sensitive access uses a second factor. Buys this to turn 2FA from an opt-in preference into an enforced, auditable policy with a coverage dashboard they can screenshot for auditors.
Runs the day-to-day Odoo instance and handles account lifecycle. Needs supported tooling to mandate enrollment per group, hand out and regenerate backup codes, reset a locked-out user's 2FA after a lost device, and revoke trusted devices — all without hacking the database or fully resetting users.
Accountable for the organisation's authentication posture across systems. Wants phishing-resistant passkeys as an option, step-up re-auth on privileged actions, and alerting when users weaken their own security, so Odoo access aligns with the wider identity and access policy.
Delivers Odoo to multiple end clients and needs a consistent, reusable enforcement layer with clean source and a git handover, so 2FA governance can be standardised across engagements rather than reinvented per project.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 MFA / 2FA Enforcement for Odoo 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 MFA / 2FA Enforcement for Odoo,然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| 2FA enforcement scope | Org-wide or per `res.groups`, policy-driven | Whatever you specify and can maintain | Often global on/off, limited group logic | |
| Enrollment grace period | Configurable countdown with cron reminders then hard-lock | Buildable but you own the scheduler logic | Sometimes present, rarely configurable | |
| Passkey / FIDO2 second factor | WebAuthn passkeys alongside authenticator TOTP | Possible with significant effort | Usually TOTP-only | |
| Compliance coverage view | Dashboard of enrollment status filterable by group | Only if you build and maintain the reports | Basic or absent | |
| Backup codes & admin reset | One-time-use codes, regenerate, audited admin reset | Depends entirely on build scope | Codes sometimes, audited reset rare | |
| Step-up re-authentication | Fresh challenge before sensitive admin actions | Custom hook work required | Rarely offered | |
| Ownership & support | Full source, git handover, support window, version-pinned | You own all maintenance and future upgrades | Vendor-locked; upgrades on their timeline | |
| Delivery model | Build-to-order, UAT on staging, rollback plan, 2–4 weeks | Timeline and quality depend on your team | Instant install but generic fit |
This is a build-to-order module, not an instant download. After a scoping call to confirm your Odoo version, edition, enforced groups, and policies, typical delivery is 2–4 weeks from confirmed scope. We build against your target version, validate on a staging copy through UAT, and only then deploy to production with a rollback plan in place.
Odoo core (`auth_totp`) provides TOTP, but it is opt-in per user — each person chooses whether to enable it, there is no way to require it, no coverage visibility, and no supported block on logins that skip it. We extend that same core mechanism with org-wide and per-group enforcement, grace periods, a compliance dashboard, backup-code and reset tooling, passkeys, and step-up re-auth. We keep Odoo's proven TOTP and add the governance layer around it.
Pricing starts from $249 as an indicative, single-company base-scope figure — a starting point, not a fixed price. Drivers such as multi-company enforcement, passkey/FIDO2 hardware rollout, deeper SSO or identity-provider integration, and larger user-migration volumes increase the quoted scope. After the scoping call you receive a fixed written quote for your exact requirements.
Every engagement includes a post-go-live support window for defect fixes and configuration adjustments, and you receive the full source via a private git repository so your team retains ownership. Because the module is version-pinned in its `__manifest__.py`, migrating it to a future Odoo release (for example 18.0 to 19.0) is handled as a separate scoped update; we can quote that when you plan the upgrade.
It is built on core modules (`base`, `web`, `auth_totp`, `mail`) available in both editions, so it works on Community and Enterprise. We confirm your edition during scoping because some surrounding behaviours differ between the two, and we build and test against your specific edition and major version (17.0, 18.0, or 19.0).
Yes. Enforcement is applied at the authentication controller and session layer rather than only the browser login form, so internal, portal, and RPC/session authentication paths that skip a required second factor are refused. We also implement step-up re-authentication so a fresh second-factor challenge can be required before sensitive administrative actions such as Settings changes.
There are two recovery paths built in. Users can consume one of their admin-issued, one-time-use backup recovery codes, and administrators can reset an individual user's 2FA for lost-device recovery — which writes an audit entry via `mail.thread` — without resetting the whole user account. Admins can also revoke trusted devices per user, and are alerted when a user disables or resets their own second factor.
A build-to-order Odoo module that turns two-factor authentication from an optional user preference into an enforced org-wide policy — mandating TOTP or passkeys per security group, with enrollment grace periods, admin-managed backup codes, and trusted-device controls. ECOSIRE builds, installs, and supports it for your Odoo 17, 18, or 19 database.