A user who can access an account can often add a new authenticator. That is convenient when replacing a phone, but dangerous if the session has been stolen. An attacker who enrols a new factor may turn temporary access into durable control of the account.
Why ordinary session validity can be insufficient
Session validity says a prior authentication event succeeded and has not been invalidated under session rules. It does not necessarily prove that the current person is the account owner at the moment a new credential is added. This distinction matters for operations that change future authentication or recovery options.
A common logic gap appears when a system demands a particular assurance level for a privileged action but lets the user enrol a new factor without re-authenticating. The new factor may then satisfy a requirement that was meant to rely on previously trusted credentials.
Require proof that predates the change
For sensitive credential changes, require re-authentication using an existing enrolled factor or a separately defined recovery ceremony. The check should happen before the new authenticator becomes trusted. Do not let the factor being added prove its own legitimacy.
Bind the challenge to the intended account, session and operation, and expire it if context changes. Prevent replay, repeated submission and cross-account use. A confirmation button in the interface cannot replace server-side validation.
Treat recovery as a different path
Legitimate users do lose their existing factors. Do not weaken normal enrolment to accommodate that case; provide a recovery method with appropriate proof and consequences. Depending on policy, recovery may require additional verification, credential removal, API-key revocation or a temporary lock.
Make these consequences transparent. If the user cannot prove control of any trusted credential, a support-led recovery process must be bounded and auditable. Avoid an unlogged support backdoor that silently installs a new login factor.
Test the transition itself
Test an attacker who has only a session, a user who still has the old factor, and a user who has lost it. Attempt enrolment after step-up expires, after a role change and from a second session. Verify new credentials are not active until required checks finish.
Inspect the audit sequence to ensure the reason for enrolment and the verification that authorised it are captured. The test should prove that policy is enforced by the server, not merely implied by a disabled button.
Put it into practice
Questions for your own system
- Require existing-factor re-authentication for sensitive enrolment where policy calls for it.
- Bind challenges to the user, session and intended operation.
- Keep recovery separate from ordinary enrolment.
- Test session theft, lost-factor and step-up-expiry scenarios.