Duress Password & Emergency Data Wipe | ObsidianX Security Controls
Protect your business data under pressure with ObsidianX. Use a duress password for instant data wipe and Code Red for secure account containment when access is compromised or forced.
By ObsidianX
Emergency controls for real operational pressure
ObsidianX is built for private commerce operators who keep customer records, sales history, supplier details, inventory, payments, staff activity, and business settings in one workspace. That concentration is powerful because everything runs from a single controlled system, but it also raises the stakes when something goes wrong. Emergency access decisions need to be handled with precision.
A standard password protects against routine unauthorised access. A recovery phrase protects against losing access. ObsidianX adds two additional layers for higher-risk situations: a duress password for immediate account destruction if the owner is forced to log in, and Code Red for trusted-contact containment when the owner cannot safely manage the account themselves.
These are not cosmetic security features. They are operational workflows designed for real pressure. They account for separation of duties, encrypted backup handling, and controlled recovery. The aim is simple: give the business owner a clear answer to a difficult scenario. If someone gains control of the login moment, what should happen to sensitive business data?
What is a Duress Password?
A duress password is a secondary password set by the account owner. It is completely separate from the normal login password and stored independently.
In ObsidianX, entering the duress password does not grant access. Instead, it triggers a destructive emergency workflow for the owner account.
The purpose is straightforward. If the owner is forced to provide a password, they have an option that does not expose the live workspace. The system treats this as a critical security event and wipes owner-scoped operational data rather than revealing it. This includes sales, customers, products, payment records, purchase orders, settings, support tickets, contact methods, staff data, inventory, and related records.
This feature is deliberately separate from password resets or account recovery. It is not designed for convenience. It is a last-resort control for situations where the safest outcome is for the hosted workspace to no longer exist in a usable form.
How the Duress Password workflow works
The duress password is configured in the Security and Recovery settings. ObsidianX requires the current password before it can be set or removed, and it must be different from the normal login password. This prevents accidental overlap with standard authentication.
During login, the system checks the normal password first. If it is correct, access is granted as usual. If it fails and a duress password is configured, the system checks the submitted password against the duress credential.
If it matches, the system recognises a duress authentication and immediately executes the wipe workflow.
The wipe runs within a database transaction. It removes all records tied to the owner account, including associated staff accounts and user-scoped commercial data, as well as the account itself.
This matters because it is not a front-end trick or a visual lockout. The data is removed at the backend level, ensuring the workspace cannot be recovered or accessed after the trigger is activated.
What is 'Code Red'?
Code Red is a trusted-contact emergency control configured by the account owner. It allows pre-authorised individuals to intervene when the owner is unable to securely access or manage the account.
Unlike the duress password, which is designed for immediate destruction under coercion, Code Red is focused on containment. Its purpose is to prevent exposure of sensitive business data while preserving the ability to recover the workspace in a controlled and verified way.
It exists for scenarios where acting alone is not safe or possible, ensuring that responsibility can be distributed without giving full operational access.
How the 'Code Red' workflow works
The owner designates one or more trusted contacts within the Security and Recovery settings. These contacts do not have normal workspace access and cannot view operational data during standard conditions.
When Code Red is triggered by a trusted contact, the system treats it as a critical security event. Active sessions are terminated, account access is restricted, and sensitive operational data is placed into a secured, isolated state.
The workflow is executed at the backend level, not just the interface, ensuring that access controls are enforced system-wide. Recovery from this state requires deliberate verification and owner-led confirmation processes, preventing immediate re-entry without oversight.
This design ensures that no single compromised moment or individual can expose or irreversibly alter the business system without controlled intervention.
In high-risk moments, the priority is control, not convenience. These emergency workflows ensure that sensitive business data is either protected or removed on your terms, not someone else’s.