Account recovery

Recovery restores authority when the normal credential path is unavailable. It must not collapse identity, possession, and existence into one fact.

Lost credentials, locked accounts, damaged devices, staff changes, and emergency operations require controlled recovery. Because recovery can replace trusted evidence, it is itself a protected action. The EAID is not an access credential and cannot become the sole recovery credential.

Recovery determines whether new authority may replace authority that is no longer usable.

The organization may require identity proofing, help-desk verification, supervisor approval, waiting periods, out-of-band confirmation, device checks, or other evidence before issuing a new credential.

Existence does not perform those tasks. It cannot establish identity merely because an identification device is present.

Possession of the EAID must never be sufficient to reset the account bound to it.

A lost identification may be found by someone who has no authority. If possession alone opened recovery, the existence mechanism would become a path around credential security.

The organization must independently establish the claimant’s recovery authority. The EAID remains a component of the governed existence relationship, not a bearer credential.

Issuing or replacing credentials is itself a consequential organizational decision.

Where the organization requires a known administrator, supervisor, or claimant to be present during recovery, it can consume the maintained existence result before the replacement is committed.

verify_existence(...)

The result supplements the recovery evidence and approvals; it does not replace them.

Normal entry and recovery entry must preserve the same credential boundary.

The first successful heartbeat releases the Rendering Agent and the organization loads its page, completing existence establishment. The recovery page still applies the organization’s claimant verification, role, workflow, and authorization requirements.

After arrival, existence maintains itself through recurring heartbeat. The network is where the organization observes the result, not the source of the claimant’s identity or permission.

The person performing the reset and the person receiving the reset may be different authorities.

A help-desk operator may execute a process for an employee. A security officer may approve it. A manager may confirm employment. Each required participant has a separate credential, role, and accountable action.

One existence result cannot stand in for all of those facts. The organization can require the current result for whichever known participant must be present at each protected step.

Recovery must close old authority as carefully as it creates new authority.

Compromised credentials, sessions, devices, and identifiers may need to be revoked. Recovery records must preserve who approved the change, which evidence was used, what was replaced, and when the prior path stopped working.

Existence can make a required participant’s current presence observable during the change. It does not perform revocation or guarantee the completeness of the recovery record.

Recovery remains vulnerable when identity proofing and organizational procedure are weak.

Existence does not prevent social engineering, insider collusion, fraudulent documents, compromised administrators, incorrect records, weak escalation, or unsafe credential delivery.

Its bounded contribution is to supply a current condition at selected recovery decisions while preserving the independent evidence required to restore authority.

Examine what changes when the person using valid authority is already inside the organization.