Assume credentials exposed to an unlocked device may need replacement.
Security concept · device-revocation foundation
Losing the hardware should not mean losing the identity inside it.
Daemonet Device Quarantine is a staged response for a lost, stolen, or compromised machine: revoke its authority now, preserve narrowly scoped owner-encrypted evidence, and decide whether to recover, retire, or wipe it later.
Concept status: signed device revocation exists today. The privileged recovery agent, evidence channel, attestation, and remote-wipe ceremony remain unshipped design work.
The central principle
Quarantine authority before destroying evidence.
A stolen device creates two separate problems: someone may reach the information or authority stored on it, and the rightful owner no longer knows where it is or what state it is in.
Immediate wipe can protect data, but it can also destroy recovery information, later integrity evidence, and the command channel. Daemonet’s identity model allows the network authority to die independently of the hardware.
Healthy peers reject the old device identity, routes, names, and service authority.
A future endpoint agent unmounts, clears, re-encrypts, or destroys selected local authority.
Normal synchronization and administration stop; only a narrow recovery role remains.
Approved device-state observations become encrypted, signed, and hash-chained.
The owner distinguishes uncertain observations from verified possession and integrity.
Restoration issues a new identity. Destruction requires stronger deliberate authority.
Explicit state, visible consequence
A device does not jump from trusted to erased.
Each transition is a signed security decision with a different authority threshold. A missed heartbeat or unfamiliar network may raise suspicion; it must not become proof of theft or an excuse for automatic destruction.
The old identity remains permanently revoked even if the hardware reconnects.
A separately authorized policy destroys selected protected material and may permanently end recovery visibility.
Cryptographically authorized commands
The recovery channel is not a remote shell.
A quarantined device accepts only a small, versioned command vocabulary. Every command names the exact device, action, policy, validity window, sequence, previous command, and required signer set.
Restore cannot replay an older command after quarantine. Wipe can require a stronger quorum than containment. No provider receives a universal recovery key merely because it delivers the command.
{
"version": 1,
"command_id": "cmd_01J…",
"device_id": "device:8e92…",
"action": "enter_quarantine",
"issued_at": "2026-07-16T04:20:00Z",
"expires_at": "2026-07-23T04:20:00Z",
"sequence": 184,
"policy": {
"revoke_service_access": true,
"seal_local_vaults": true,
"enable_recovery_reporting": true
},
"previous_command_hash": "sha256:91b7…",
"signatures": ["owner:…"]
}
- An enrolled owner or recovery authority signed the exact envelope.
- The device identifier and permitted action match local policy.
- Validity, sequence, prior-command hash, and replay state all pass.
- Every required co-signature is present.
- The requested operation stays inside the recovery vocabulary.
One owner key may quarantine. Restore may require physical confirmation. Wipe may require two devices or one device plus a separate recovery key.
The endpoint recovery agent
Security infrastructure—not a rootkit.
The proposed agent is a small privileged service installed during legitimate ownership. Its narrow job is to receive signed commands, change device state, seal local authority, create approved encrypted observations, deliver them, and acknowledge execution.
It must be visible to the legitimate administrator, removable after verified recovery, and incapable of spreading, scanning arbitrary networks, or accepting arbitrary code execution.
- receive exact signed commands
- seal selected local authority
- record approved device state
- encrypt reports to the owner
- send through approved routes
- perform a separately authorized wipe
- record people or conversations
- read unrelated user content
- capture passwords or keystrokes
- scan or exploit nearby systems
- hide from the rightful administrator
- resist valid ownership transfer
The agent belongs only on a device the installer owns or is explicitly authorized to administer. Employers may revoke their own persona and data without gaining personal recovery authority. A sale or transfer must permanently remove every prior owner and report destination.
Owner-encrypted evidence
Record the device’s state—not the person holding it.
Each approved event can bind sequence, boot identifier, monotonic and trusted time, event type, encrypted-payload hash, and the previous event hash, then receive a device or hardware-backed signature.
The journal can expose tampering or missing entries. It cannot prove a compromised firmware stack told the truth, turn an approximate IP region into an address, or make a cryptographic record automatically admissible in court.
HASH(sequence + boot + time + type + ciphertext_hash + previous_hash)DEVICE SIGNATUREIntegrity and operation
Boot and shutdown, secure-boot status, failed unlock count, power, disk health, interface state, and hardware or time-source changes.
Narrow observations
The device’s addresses, connected access-point BSSID, gateway, signed public-IP observation, reachability, latency, and an explicit confidence level.
Encrypt before delivery
SSID, BSSID, gateway identifiers, IP addresses, and permitted location readings are encrypted directly to the owner or authorized recovery group.
Keyed fingerprints
An owner-secret HMAC can show that the same network reappeared without exposing the raw identifier to a storage or delivery provider.
Offline first, store and forward
A missing device may reconnect weeks later.
The endpoint queues a signed event, encrypts its payload to the owner, retries only through legitimately available owner-approved connectivity, and removes the delivery item only after a receiver signs an acknowledgement.
Multiple drop points can reduce availability risk. A personal Daemon, organization security system, 1Man, another provider, or an encrypted object store can carry ciphertext without becoming identity or evidence authority.
recovery_channel · sequence · ciphertext · ciphertext_hash · device_signatureNO PLAINTEXT REPORT REQUIREDRecovery and destructive action
The more irreversible the step, the stronger the authority.
Unexpected signals should usually request confirmation. Owner-confirmed wipe is the safest ordinary default. Automatic integrity or location triggers require much stronger engineering, testing, and policy because a false positive can destroy the only surviving data or evidence.
Immediate authority revocation
Remove the device from trusted services even while it remains offline. Publish a bounded quarantine command for its next permitted contact.
ONE OWNER MAY SUFFICENever restore old trust
Verify possession and integrity, reinstall when appropriate, generate a new hardware-backed key, re-enroll, and retire the old identity permanently.
PHYSICAL CHECK + FRESH IDENTITYDestroy deliberately
Choose immediate, delayed, integrity-triggered, location-aware, or explicit-only policy before loss—and understand that evidence visibility may end.
QUORUM OR SECOND CONFIRMATIONBeyond laptops and phones
Quarantine the implementation. Preserve the service identity.
The same authority split applies to an organization laptop, server, contributed node, virtual machine, container, kiosk, or field device. A compromised instance can stop work and remain inspectable while a clean replacement inherits only freshly authorized service authority.
Bound the employer role
Revoke corporate identities and data, require quorum for sensitive actions, retain only declared evidence, and preserve employee-private personas.
Isolate suspicious infrastructure
Stop workloads, remove service identities, seal volumes, preserve logs, and retain only a restricted incident-response channel.
Stop earning and serving
A suspicious node no longer stores new shards, relays traffic, runs compute, issues proofs, or earns contribution credit.
Freeze the instance
Snapshot, revoke secrets, remove normal networking, move to an isolated analysis segment, and issue a clean replacement identity.
Identity outlives the host
The stable service can move to a replacement while the compromised machine remains quarantined and unable to impersonate it.
Export with limits
Provide signatures, chain validation, commands, acknowledgements, measurements, and confidence notes without promising legal admissibility.
Evidence state
A compelling security design is not a shipped recovery product.
This example extends naturally from Daemonet’s owner-controlled identity model, but each privileged endpoint and destructive action needs platform-specific implementation, external security review, abuse analysis, and destructive failure testing.
Signed device revocation
Owner-approved removal converges, tears down the revoked local peer, and removes its authenticated profile, WireGuard, private-DNS, publication, and synchronization authority.
Quarantine command and journal
Envelope fields, state transitions, recovery quorums, chained evidence, encrypted store-and-forward, and signed receipts still require a formal versioned protocol.
Privileged recovery agent
Linux, Windows, macOS, mobile, TPM/secure-enclave behavior, full-disk encryption, secure boot, offline queues, and clean removal need separate implementations.
Safety before remote wipe
Ownership transfer, stalking and employer-abuse defenses, false positives, quorum loss, firmware compromise, destructive wipe, restore, and evidence-export canaries must pass.
A powered-off or radio-disabled device may never receive a command. Physical attackers can destroy or replace hardware. Network identifiers can be moved or spoofed. Firmware compromise can undermine software evidence. Quarantine protects network authority first; it is not perfect tracking or a guarantee of hardware recovery.
The device is one representative—not the owner