MFA reduces the risk that a stolen password is enough to access an account, but it can create an operational problem when a mobile phone is lost, a device is replaced, or the person who administered a service leaves the company. If no one can recover access to WordPress, hosting, or DNS, a simple technical incident can become a disruption that is difficult to manage.
The problem is not solved by sharing codes, leaving a personal email address as recovery, or creating permanent exceptions. The alternative is an MFA recovery plan limited to critical accounts, with internal responsible parties, validation proportionate to the impact, and a defensive review after each recovery. The goal is to restore authorized access without turning the process into a back door.
MFA recovery is also a sensitive action
An account may be well protected at sign-in and still be exposed if it is too easy to change its phone number, register a new passkey, or modify the recovery email address. OWASP recommends that MFA reset should allow legitimate access to be recovered without enabling account takeover. It also advises requiring fresh authentication with an already registered factor before changing MFA factors, rather than relying only on a session that may have been compromised. [3]
The loss of the second factor should be treated as a continuity and security process, not as an informal request through chat. The person requesting the change must be identified through a defined channel, and the decision must be recorded. When the account can publish content, modify DNS, restore backups, or view customer data, a second internal approval may be a reasonable measure.
- Require a request through the agreed internal channel.
- Verify the identity and reason before changing or removing a factor.
- Record who authorized the action, when it was performed, and what must be reviewed afterwards.
Define the accounts included in the plan
There is no need to start with every company account. Prioritize those that can affect the availability, configuration, or information of the website: CMS administration, hosting, DNS, corporate email, CDN or WAF, e-commerce platform, and identity provider. ENISA recommends deciding which assets and roles require MFA according to their criticality, defining secure backup methods, and monitoring authentication logs. [4]
Classify each account by its ability to cause impact, not by the job title of the person who uses it. The same person may have access to several providers, but each service will have its own support mechanisms, evidence requirements, and timeframes. For example, an account that modifies DNS records needs a different recovery path from the editorial account that publishes a blog post.
- Service and official access URL.
- Internal owner and second authorized responsible party.
- Privilege level and actions the account allows.
Create a recovery record for each provider
For each critical platform, prepare a brief record accessible only to those who need to use it. It should state who can open a request with the provider, which internal checks are performed, what the official support channel is, and which changes require dual review. Avoid including passwords, temporary codes, authenticator seeds, or other secrets in shared documents.
NIST contemplates mechanisms such as recovery codes, recovery contacts, and repeating identity verification. It also indicates that recovery events should generate notifications to help detect fraudulent use. If a provider offers recovery codes, safeguard them according to an internal policy and review their validity whenever the authorized responsible parties change. [1]
- Official recovery route and the provider's contact details.
- Internal evidence or approvals required before starting the process.
- Mandatory subsequent steps: review of factors, sessions, and recovery contacts.
Respond differently depending on the incident
When a device is lost or replaced, the objective is to enroll a new factor without rushing to remove the previous one if its status can still be verified. A hypothetical example: the person responsible for content changes phones and retains access to the corporate account. A second responsible party validates the request, the new factor is registered through the official process, and it is then confirmed that old factors that are no longer needed have been removed.
An employee departure or suspected compromise requires greater caution. In the first case, access and recovery methods linked to that person must be removed according to the authorized scope. In the second, recovering the password is not enough: OWASP advises reviewing MFA methods, recovery addresses, active sessions, and recent changes, and invalidating sessions or recovery links that should no longer remain valid. [5]
- Device loss: validate the request and register the new factor.
- Employee departure: remove associated permissions, factors, and contacts.
- Suspected compromise: review sessions, recent changes, and recovery data before closing the case.
Test the process and improve what fails
A procedure that has never been tested may depend, without anyone knowing, on a specific person or outdated information. Carry out controlled tests, with prior authorization and on accounts or environments intended for that purpose. The test does not seek to force access: it verifies that the team can locate the record, identify the responsible party, use the provider's official channel, and document the result.
Review the plan after changes to providers, personnel, domains, roles, or authentication methods. For higher-value or more privileged accounts, CISA recommends prioritizing phishing-resistant MFA and starting with compatible services and groups such as system administrators or support teams. Manually entered OTP codes may still have operational usefulness, but NIST does not consider them phishing-resistant because they can be relayed from an impostor site. [2] [1]
- Schedule a periodic review and another one after relevant changes.
- Record the test date, detected issues, and the person responsible for correcting them.
- Update the record only after verifying that the new route works.
Frequently asked questions
Should we store MFA recovery codes in a shared document?
It is not advisable to store codes, passwords, or MFA secrets in generally used shared documents. If the provider offers recovery codes, the company can define restricted custody, access controls, and reviews when responsible parties change. The operational record should indicate where the approved mechanism is, not expose it,
Should two responsible parties share the same administrator account?
No. It is preferable for each responsible party to have their own identity and permissions appropriate to their role. This makes it possible to remove individual access, review activity, and maintain a recovery path without sharing passwords or MFA factors. When the provider allows it, assign differentiated roles instead of using a single shared,.
How often should the MFA recovery plan be reviewed?
Review it periodically and whenever there are relevant changes: employee departure or onboarding, device replacement, provider change, addition of a domain, or modification of privileges. A controlled test makes it possible to detect outdated contacts, incomplete instructions, or dependencies on a single person before one occurs.