The details are useful for finding the account. They are not strong evidence that the person in chat controls it. Invoice amounts and ticket IDs can appear in forwarded mail, screenshots, billing exports, or a breached mailbox. The agent can be confident it found the right record and still be talking to the wrong person. Removing MFA is a change to the mechanism that protects the account, so I would keep the reset tool behind an account recovery service rather than authorize it from a persuasive support conversation.

The recovery service owns a documented set of methods and risk rules for the account's assurance level. Depending on enrollment, those may include a saved recovery code, a code sent to a previously verified recovery address, an existing bound authenticator, a prearranged recovery contact, or repeat identity proofing. NIST SP 800-63B distinguishes account recovery from ordinary authentication and specifies methods and notification requirements for the systems in its scope. The precise method here depends on the product's enrollment and assurance contract. The agent can explain the options, start a recovery case, and route the customer through the approved flow. It cannot invent an alternative by asking knowledge questions the user and an attacker may both answer.

There are several identities to keep apart. The person in chat has an unverified claim to an account. The support supervisor has employee authority to review an exception, but that authority does not prove the claimant's identity. The agent and recovery service have workload identities. A supervisor's “looks convincing” message should not become a bearer approval for remove_mfa. If an exception process exists, it must specify what proof is required, who can approve, whether two independent reviewers are needed, which account is affected, expiry, and what action is permitted. The recovery service enforces it and logs the decision. The model does not hold the reset credential or get to turn a chat summary into a verified factor.

Now the mailbox may be compromised. Do not send the sole recovery code or notification to that address and call it independent proof. Use a previously enrolled alternative method where one exists, and check whether recent changes to recovery addresses or devices are themselves suspicious. An attacker who can edit the account's recovery address immediately before opening a chat must not get credit for a “previously verified” address. The policy may require a waiting period, a second channel, or human identity proofing for this case. We should be honest about the cost: a legitimate customer may wait longer. Bypassing the factor because support is busy makes the recovery path the weakest login path.

If the customer already has a valid session at a suitable assurance level, the case may be a new authenticator binding flow rather than full account recovery. If not, the agent should say it cannot remove MFA through chat and give a concrete next step. Do not disclose whether a guessed email has an account or reveal invoice details while explaining the denial. Rate limits, abuse monitoring, and privacy-preserving case status matter because an attacker can probe many accounts through support.

After a permitted recovery, notify the subscriber through the configured independent channels and make the security event visible. NIST's guidance calls for recovery notifications, which help detect fraudulent use. Test a stolen mailbox, leaked invoice, attacker with an old support ticket, recently changed recovery contact, legitimate lost-device case, and a supervisor who tries to override the workflow. Measure fraudulent resets and legitimate recovery completion together. A fast recovery flow that silently opens accounts is not a customer service improvement.