Most B2B secrets managers provide no in-app tooling to handle an incident: you have to open a support ticket, wait for human intervention and explain the situation to a sales rep. ARDNTECH makes the opposite choice: a dedicated panel in the organisation settings, two graduated actions, a mandatory written justification, a tamper-proof HMAC audit chain. Designed so that a CISO can react in seconds, with no dependency on our team.
A secrets manager concentrates by design an organisation's most sensitive value. When an incident is suspected, the reaction time determines the scale of the damage. Three situations require immediate in-app tooling, with no detour through support.
An employee reports suspicious behaviour on their machine, their session cookie may have been siphoned off by a malicious extension, their phone has just been stolen. You must block their access to the organisation's secrets without affecting their other professional engagements and without losing the forensic trail.
Mass phishing identified, theft of administrator credentials, suspicion of deep infiltration: you must freeze all of an organisation's access in seconds, without risk of missing a member, and with a tamper-proof trail for the subsequent investigation.
The GDPR requires the notification of a personal data breach to the supervisory authority within 72 hours, and in certain cases to the data subjects. The DPO and the CISO need an enforceable, dated and tamper-proof log, listing the actions taken and their written justification.
Level 1 addresses the most frequent situation: a targeted suspicion on a specific organisation, without certainty of a wider compromise. The impact remains strictly scoped. No user is logged out of their other organisations.
The service sets an end-of-access timestamp on every member of the organisation. All routes return a dedicated 403 code, accompanied by an <code>X-ARDNTECH-Org-Suspended</code> header. The local metadata cache on the browser side and the extension side is purged for this organisation on the next request.
A consultant who belongs to three client organisations can be suspended on one of them without losing access to the other two. Their web session remains valid, their personal vault stays unlocked, their secrets from another organisation remain readable. Strict scoping, with no collateral damage.
Once the situation is clarified, the same panel offers reactivation via a dedicated button. The action is itself recorded in the audit chain (<code>org_membership_resumed</code>). No manual database manipulation, no dependency on ARDNTECH support.
Each suspended member receives an email reproducing the reason written by the administrator. The organisation's other administrators receive a social-control notification, so that an abusive trigger is immediately visible to their peers.
Authorised roles
Only the <strong>Owner</strong> and <strong>Admin</strong> roles of the organisation concerned. No Member role can trigger the suspension, even by accident. Administrators of another organisation have no visibility into and no power to act on the impacted organisation.
Mandatory written justification
The triggering party must enter a detailed reason in a free text field. No « no reason » option exists. The reason is recorded verbatim in the HMAC audit chain and reproduced in the notification emails sent to the affected users.
Two-step confirmation
The confirmation modal requires the organisation name to be re-typed, on the GitHub « type the repo name to delete » pattern. This deliberate friction prevents any accidental trigger by reflex click.
MFA re-authentication
Before application, the administrator must re-enter their password and validate an MFA step (TOTP, WebAuthn or backup email). A stolen session cookie is not enough to trigger the suspension.
Each trigger produces a typed <code>org_membership_suspended_emergency</code> entry in the HMAC-SHA-256 audit chain. The entry contains the organisation identifier, the acting administrator's identifier, the written reason, the list of affected users (by identifier and SHA-256 hash of the email), the count of impacted members and the timestamp. The chain is verifiable from a public command line according to the mechanism described on the <a href="{link}">HMAC audit chain page</a>.
Level 2 addresses situations where the compromise extends beyond the scope of a single organisation: a user device infected by malware, a stolen computer without full disk encryption, suspicion of an attacker's persistent presence. The action is deliberately broader and more destructive. It should only be triggered as a last resort.
All active web sessions of the members are killed server-side. The local vaults of the affected users are re-locked on the next tab refresh. The « remember me » feature is revoked. Users are forced to re-authenticate fully, including from their other organisations.
When the user's own device is suspected, the compromise is no longer limited to one organisation: the attacker likely has access to all the organisations the user belongs to. A surgical suspension would be insufficient. The cross-org effect is claimed and documented.
Physical theft of a device without screen decryption, malware identified on a key employee's machine, a strong EDR endpoint signal, strong suspicion of an internal attacker with access to the machine. For more contained suspicions, level 1 remains the right choice.
The three safeguards of level 1 apply identically to level 2: mandatory reason text, re-typing the organisation name to confirm, administrator password and MFA re-authentication. The friction is deliberate, proportionate to the impact.
The trigger produces an <code>org_security_emergency_lockout</code> entry in the HMAC chain, containing the count of killed sessions per user. Beyond three triggers on the same organisation in under an hour, an internal alert is raised to the ARDNTECH support team and an email is sent to the organisation's billing contact, so that administrator abuse is detected quickly. No automatic blocking: a genuine emergency may require several consecutive triggers.
A tab already open on the application at the moment of the lockout may retain cached metadata until its auto-lock or refresh. The web session is killed, so any subsequent fetch forces a re-login. This limitation is documented in the architecture notes and will be handled by WebSocket push in V2. The vault unlocked in memory in an existing SharedWorker follows the same lifecycle: it re-locks on the next tab refresh.
The operational security page dovetails with the overall response plan already published in the threat model. The table below summarises the three standard levels, from surgical to external communication.
| Level | Trigger | Action |
|---|---|---|
| <span class="m-tag m-tag--info">L1</span> Surgical suspension | Targeted suspicion on one organisation: compromised user account, HR report, audit log anomaly. | Blocking access to the organisation's secrets and folders for all its members. No cross-org impact. Reversible via a dedicated button. |
| <span class="m-tag m-tag--warning">L2</span> Emergency lockout | User device compromise, device theft, strong suspicion of an internal attacker with access to the machine. | Invalidation of all web sessions, re-locking of vaults, « remember me » revocation. Assumed cross-org impact. |
| <span class="m-tag m-tag--danger">L3</span> External communication | Technical compromise confirmed by internal or external investigation with exposure of personal data. | CNIL and ANSSI notification within 72 hours (GDPR Art. 33), transparency report published, external forensic audit commissioned. |
Levels L1 and L2 are tooled in-app in the organisation settings panel. Level L3 falls under an organisational procedure jointly driven by the DPO and the publisher, triggered by a written decision and traced in the audit chain (<code>incident_l3_external_notification</code>).
ARDNTECH commits to a response plan aligned with GDPR obligations for incidents involving personal data. The plan is aligned with the public posture of the threat model and with the privacy policy.
In the event of an L3 incident affecting personal data, ARDNTECH notifies the CNIL within the time limit provided for in Article 33 of the GDPR. The notification includes the nature of the breach, the categories of data subjects, the likely consequences and the measures taken. Customer data controllers are informed in parallel so that they can meet their own obligations.
Every L3 incident is the subject of a transparency report published on the website, after agreement from the authorities and anonymisation. This report details the chronology, the technical causes, the corrective measures put in place and the lessons learned. Transparency is a lasting commitment, not a commercial option.
In the event of an L3 incident, an independent forensic audit is commissioned from an ANSSI-referenced PASSI provider or an equivalent firm. The summary report is shared with Business and Enterprise customers under NDA, and an anonymised public summary is included in the transparency report.
The table below compares the availability of in-app incident response tooling across several B2B secrets managers. The information is drawn from public documentation as of 2026-08-01 and may change. No qualitative judgement is made about the overall quality of the products cited, all recognised in their category.
| Publisher | Surgical org suspension | Global emergency lockout | Justification mandatory in the audit chain |
|---|---|---|---|
| ARDNTECH | Oui · in-app · panneau dédié | Oui · in-app · panneau dédié | Oui · HMAC-SHA-256 vérifiable en commande publique |
| Bitwarden | Selon documentation publique : suspension manuelle par retrait de l''utilisateur, pas de panneau dédié « incident ». | Selon documentation publique : pas d''action « kill all sessions for org » en console admin self-service. | Audit log présent, sans chaînage cryptographique vérifiable hors plateforme. |
| 1Password Business | Suspension d''utilisateur granulaire, sans bouton « gel d''organisation » dédié dans la documentation publique consultée. | Selon documentation publique : déconnexion par utilisateur, pas d''action de masse automatisée pour une équipe entière. | Audit log présent avec horodatage, signature cryptographique chaînée non documentée publiquement. |
| Dashlane Business | Suspension utilisateur via la console admin, sans panneau « réponse à incident » identifié dans la documentation publique. | Selon documentation publique : pas d''action de déconnexion globale dédiée avec justification obligatoire. | Audit log présent, modèle de chaînage cryptographique non documenté publiquement. |
| NordPass Business | Suspension utilisateur classique en console admin, pas de panneau « réponse à incident » dédié dans la documentation publique. | Selon documentation publique : pas d''action « lockout global org » en self-service avec garde-fous documentés. | Activity log présent, modèle de chaînage cryptographique non documenté publiquement. |
| Proton Pass Business | Gestion des accès par espace partagé, suspension utilisateur disponible dans la console admin selon documentation publique. | Selon documentation publique : pas d''action de déconnexion globale dédiée avec workflow distinct du retrait d''utilisateur. | Audit log présent, modèle de chaînage cryptographique non documenté publiquement à date. |
| Passbolt | Suspension utilisateur en console admin, outillage incident-response dédié non documenté à date dans la documentation publique consultée. | Selon documentation publique : pas d''action « kill all sessions for org » en self-service avec justification obligatoire. | Activity log présent, chaînage HMAC public non documenté à date. |
Sources: publishers' public product documentation consulted as of 2026-08-01. Most competitors offer effective user removal for offboarding; ARDNTECH's specificity is to formally distinguish the « incident suspension » operation from the « user removal » operation, with a dedicated panel, a mandatory justification, a verifiable HMAC audit chain and a two-level graduated workflow. If any information seems inaccurate to you, contact legal@aegirex.eu: this page is updated promptly.
The incident response module is included in every ARDNTECH plan, including the free plan. It is part of the publicly claimed « security beyond the paywall » foundation. Request access to the private beta to test surgical suspension and emergency lockout on a pilot organisation, or read the full threat model to understand the overall defensive posture.
