Two requests turned out to be the same problem. In one, a critical module had been uninstalled by someone with admin rights, and the client wanted a second lock another admin couldn't casually bypass. In the other, nobody was sure how exposed Odoo's database manager was, or whether the backups would work in an emergency.
The obvious designs fail in the same way. A PIN reset stored in the database can be performed by anyone with database access. A security setting stored in the database can be switched off by the very admin account it is meant to contain.
So we moved the switch. Module locks hash every PIN, and the recovery secret lives in the server config file — database access alone can't reset a lock. The guard on the database-manager routes, with IP allowlisting, failed-login lockout and audit logging, reads every setting from the server config too, so a compromised admin account can't disable its own guard rail.
That's a privilege separation rather than a feature. The people who can change the database and the people who can change the server are different people, and the secret goes to whichever side the threat isn't on.
Our security hardening looks the same on both platforms even though we built it a year apart, independently. That's a house pattern, not a coincidence.
Read the case study: A second lock on the modules the business can't lose