MeldID Introduces Panic Mode: What Happens When You Can No Longer Trust Your Account Access

In my previous article about MeldID, I explained how the system operates in regular mode: it manages a controlled profile, assists with logging into connected services, synchronizes TOTP records across devices, and allows confirming new authorizations through a mobile app.

But every identification system has a scenario that is often remembered too late: what should one do if they no longer trust the current access to their account?

It's not necessary to already know that a breach has occurred. Sometimes, an unexpected password reset email, unknown session, or login from an unfamiliar device is enough to cause concern.

For such situations, MeldID has introduced two new mechanisms: delayed password change and panic mode.

First, understanding how the MeldID password system is built

In MeldID, users do not create their own passwords — they are generated by the system. This immediately excludes weak or predictable combinations, reuse of familiar passwords, and other issues related to manual selection.

Moreover, the active password is not sent to the user by email. The email account is not a place where the current MeldID password can be retrieved.

The recovery process also does not reveal the old password. It simply initiates the creation of a new one.

Therefore, compromising an email account creates another threat: someone who gains access to the email may not know the current MeldID password but can attempt to trigger the recovery process and set a new one.

This scenario was one of the reasons why the recovery logic needed to be changed.

Password no longer changes instantly

In the typical recovery scenario, everything happens almost immediately. The user requests a new password, receives a notification email, and completes the process.

This is convenient when the email account is under the owner’s control. But if an attacker gains access, immediate recovery turns the email into a direct route to hijack the associated account.

In MeldID, a password request first becomes a warning rather than an immediate change. The user receives a notification about the recovery attempt, and then a waiting period begins.

The duration of this period can vary, but the principle remains the same: there is a window between the request and the actual activation of the new password, allowing for situationAssessment.

The old password still remains valid during this time. Therefore, the mere initiation of recovery does not automatically mean control has shifted to an attacker.

If the app is unavailable

There is an important scenario that is easy to overlook. The user may initiate the password recovery but not have access to the MeldID app: the phone is lost, broken, out of battery, or temporarily inaccessible.

In this case, recovery can still complete automatically once the waiting period expires. The new password will become active without the app being needed for confirmation.

So, someone who started the password change and cannot open the app now doesn’t need to restart the process. They just need to wait for it to finish and use the new password to log in.

If the app is available, the options increase: the user can immediately activate the new password or cancel the suspicious request. If access to the app is unavailable, the delayed recovery process continues unchanged.

Users decide what to do next

If the recovery was legitimately initiated by the account owner and the app is at hand, they can activate the new password immediately without waiting for the period to end.

If the request was unexpected, it can be canceled via the app. In this case, the old password remains valid and the account is not compromised.

This is an important change in the recovery logic. The system no longer treats any request as legitimate solely because it was initiated through email. It allows the account owner to intervene and make decisions through a trusted mobile device.

Imagine a common situation: the user receives a notification of a password change they did not request. They cancel the operation in the app, then investigate the email, check devices, and look for suspicious activity.

MeldID cannot regain control over a compromised email account, but it can prevent the email breach from immediately resulting in changing the main account’s password. It delays the process and allows the owner to verify and restore control over their email.

Panic mode revokes active access

The delayed password change helps buy time. Panic mode is intended for a scenario where this is no longer enough, and the user wants to instantly terminate previously granted access.

It is activated through a single action in the mobile app.

Upon activation, the system revokes all active tokens — access keys used by apps and websites to verify login status. Simultaneously, it terminates existing sessions on mobile clients and web browsers associated with the account.

This means not only the current session on the phone ends. Revocation extends to other smartphones, tablets, browsers, and connected apps where prior login was made.

The mode remains active for a set period, which can vary. Its principle remains: existing access is terminated, giving the user protected time to assess the situation.

Panic mode does not delete user data

The name might sound drastic, but it’s important to clarify what it does not do.

Panic mode does not wipe TOTP records, stored profiles, settings, or any other user data. It does not clear account content or turn the account into an empty shell.

It changes the access state: active tokens are revoked, and open sessions are terminated. When returning to normal mode, stored data remains intact and does not need to be re-added.

This is the fundamental difference between emergency access termination and account data destruction. Users can disconnect existing integrations without risking the loss of their profiles or configurations.

What happens to password changes during panic mode

Panic mode has another crucial rule: it cancels all incomplete password change attempts.

It does not matter whether the new password was requested before panic activation or during its operation. Such requests cannot automatically complete after the mode ends.

After panic mode concludes, the current password remains the one set before activation.

This was done intentionally.

Standard recovery procedures assume the user can see suspicious requests in the MeldID app and cancel them before the new password takes effect. During panic, this scenario cannot be relied upon.

Suppose a user notices suspicious activity and activates panic mode. If they allow the normal recovery timer to continue working, an attacker could request a new password during the panic. If the waiting period ends before the panic mode is lifted, the new password would become active, potentially before the account is restored.

This could create a paradox: the user enabled enhanced protection, but during this period, the system permitted a password change without the owner’s ability to cancel it via the app.

Therefore, panic mode does not pause recovery for later continuation. It terminates ongoing recovery processes.

Requests made before panic activation cannot change the password after the mode ends. The same applies to requests initiated during the mode’s active period.

Nothing from an unfinished recovery persists across the panic boundary.

What if the user wants to change the password first

Panic mode does not restrict the owner’s sequence of actions. If they have access to the MeldID app and believe changing the password is necessary, they can first initiate the password change and confirm the new password through the app.

In this case, the change completes before panic mode activates.

Afterwards, the user can activate panic mode with the new active password. This password will remain after the mode is lifted.

Alternatively, the user can first enable panic, investigate the suspicious activity, and after resolving the issue, initiate a new password change if needed.

The key point is that the mechanism isn’t designed to enforce a fixed sequence of actions. The main rule is that an unfinished password change should not survive the panic mode.

Panic mode provides time to regain control over email

This mechanism is particularly relevant if the user suspects that the issue does not stem from MeldID or the device, but from their email account.

Since email is a recovery channel, its compromise remains dangerous even if the MeldID password itself remains unknown to an attacker.

In such cases, the user can enable panic mode and focus on restoring email access: reset the email password, terminate unknown sessions, and review security settings.

While panic is active, MeldID does not permit recovery procedures to generate a new active password.

If an attacker already requested recovery before panic, this attempt is canceled once panic is activated. Any new requests during the period will also be blocked.

This creates a protected window: MeldID access tokens are revoked, the compromised email cannot be used to prepare a new password before the mode ends, and the owner has time to regain email control.

Once panic mode ends, the previous MeldID password remains active. If email control has been restored and no other issues are present, the user can continue using the account normally.

If they decide to change the MeldID password after review, it can be done separately.

Reasons to activate panic mode can vary

Activating this mode does not require proof of hacking beforehand.

The phone might be in someone else’s hands. An unknown session could be present in the device list. The user might receive unexpected login or recovery notifications. Sometimes, suspicion arises from a combination of small signs rather than a single obvious event.

In such situations, it’s not always necessary to conduct an investigation before initial protective action. Temporarily revoking active access and then checking details is often more prudent.

MeldID operates on simple logic: if the owner considers the situation dangerous and has access to a trusted app, they should be able to immediately activate the protective scenario. The system does not require proof of an attack first.

Why changing the password alone may be insufficient

The password is just one element of authorization. If there is already an active session or an issued access token, changing the password alone does not automatically revoke all earlier accesses.

This is why panic mode goes beyond: it doesn’t simply change one account parameter but shifts the entire account into an isolated protective state.

The sequence is as follows:

1. Active sessions and tokens are revoked;

2. Incomplete password change attempts started before panic are canceled;

3. Recovery requests during panic cannot change the password after it ends;

4. The account remains with the password used before entering panic mode;

5. The user gets time to review email, devices, and potential points of compromise;

6. After exiting the protective mode, they return to normal operation or initiate a new password change if needed.

This is not a replacement for standard security mechanisms but an emergency scenario for moments when trust in current access status is temporarily lost.

The mobile app as a trusted control point

New features are available in MeldID apps for iPhone and Android. In this architecture, the phone becomes not just another login device but a trusted security management point for the account.

Through the app, users can:

• confirm delayed password changes;

• cancel suspicious requests;

• activate panic mode;

• terminate active sessions on multiple devices;

• define further account actions.

The mobile app does not disable TOTP nor replace other security methods. It adds a separate control channel for cases where usual login procedures are no longer sufficient to assess account safety.

Understanding MeldID’s protection boundary

It’s important to differentiate between MeldID’s security mechanism and the security of the environment in which it operates.

MeldID is designed so that the service itself does not create a default channel for obtaining the active password. The password is generated by the system, not chosen by the user, and never transmitted via email. Recovery does not reveal the existing password but initiates a new one creation process.

However, users can still disclose their credentials intentionally or accidentally, for example, by sharing them or entering them elsewhere where it shouldn’t happen.

Another level involves device and operating system security. The mobile app operates within the security frameworks provided by iOS and Android and cannot replace platform security itself.

Therefore, MeldID focuses on risks manageable on its side: credential generation, authorization, tokens, sessions, recovery, and responses to potential compromise of recovery channels.

From login to response

When I was first introduced to MeldID, it could be described as a unified identification and profile management system. After the release of mobile apps and new protection mechanisms, that description became too narrow.

Now, the system addresses not just “how to log in,” but more complex questions such as:

• what to do if recovery is suspected to be malicious;

• how to restore access without app access;

• how to gain time for verification before activating a new password;

• how to cancel recovery initiated without the owner’s consent;

• how to revoke active sessions;

• how to prevent compromised email from changing passwords during an emergency;

• how to regain control over recovery channels;

• how to preserve user data when terminating all active access;

• how to return to normal operation after verifying the situation.

Ultimately, this creates a layered protection model.

The active MeldID password is never transmitted via recovery channels. Email access alone does not reveal it but can trigger a new password process. Recovery is intentionally delayed and can be canceled through a trusted app.

If that’s still insufficient, panic mode terminates sessions, revokes tokens, and prevents unfinished recovery from surviving the protective period.

The user gains what is especially critical in an incident: time.

Time to regain control over email, verify devices, investigate the issue, and only then restore normal account access.

This is why MeldID’s panic mode is not just a “log out everywhere” button. It is a dedicated incident response scenario, essential when regular login methods no longer suffice, requiring trust restoration first.

For more information: meldid.de.