Derivative works

DEFENSIVE DISCLOSURE

Title: Methods and Systems for Dynamic, Context-Aware Endpoint Quarantine and Remediation Across Heterogeneous Networks

Publication Date: May 13, 2026

Abstract: This disclosure describes a series of novel implementations and derivative applications of trusted computing-based network access control. The described techniques expand upon the core concept of attesting to an endpoint's security posture by introducing variations in components, operational scales, cross-domain applications, integration with emergent technologies, and fail-safe operational modes. The purpose of this publication is to place these concepts into the public domain, thereby establishing them as prior art for any future patent applications in these areas.

---

Axis 1: Material & Component Substitution

This section explores alternative hardware and software components to achieve the functional result of secure attestation and quarantine, as outlined in US patent 9,516,048.

Derivative 1.1: Attestation via Physical Unclonable Functions (PUFs)

• Enabling Description: Instead of a software-based digital signature from a Trusted Platform Module (TPM) or general trusted computing base, this method uses a hardware-based Physical Unclonable Function (PUF) embedded in the endpoint's silicon. The PUF generates a unique, unclonable challenge-response pair (CRP) that serves as the device's fingerprint. The network access controller (NAC) stores a whitelist of valid CRPs for known-good devices. Upon connection, the NAC issues a challenge to the endpoint. The endpoint's PUF generates a response. If the response matches the stored value, the device is trusted. If not, or if the device fails to respond, it is shunted to a quarantine VLAN. Remediation involves an administrator physically vouching for the device to register its unique CRP signature with the NAC. This method is particularly robust against software-level spoofing.

• Diagram:

  sequenceDiagram
      participant Endpoint as Endpoint (with PUF)
      participant NAC as Network Access Controller
      participant Remediation as Remediation Server
  
      Endpoint->>+NAC: Request Network Access
      NAC->>-Endpoint: Issue PUF Challenge
      Endpoint->>+NAC: Return PUF Response
      NAC->>NAC: Verify Response against Whitelist
      alt Response is Valid
          NAC-->>Endpoint: Grant Full Network Access
      else Response is Invalid/Missing
          NAC-->>Endpoint: Route to Quarantine VLAN
          Endpoint->>+Remediation: Display "Manual Registration Required" Page
      end
  

Derivative 1.2: Quarantine via Browser-Native WebAssembly (WASM) Sandbox

• Enabling Description: This method replaces a network-level redirect with a client-side enforcement mechanism. A lightweight agent on the host, or a mandatory browser extension, performs the cleanliness check. If the host fails, the agent instantiates a sandboxed WebAssembly (WASM) module within the browser. This WASM sandbox acts as a proxy for all of the browser's outbound network requests. It inspects each request and only allows connections to whitelisted remediation server hostnames and IP addresses. All other requests are programmatically dropped or redirected to a local data:text/html page explaining the quarantine state, removing the need for a network-level DNS or HTTP redirector.

• Diagram:

  flowchart TD
      subgraph Endpoint Browser
          A[User attempts to access evil.com] --> B{WASM Quarantine Proxy};
          B -->|Is destination a whitelisted remediation server?| C{No};
          C --> D[Request Blocked];
          D --> E[Render Local Quarantine Page];
          F[User attempts to access patch.vendor.com] --> B;
          B -->|Is destination a whitelisted remediation server?| G{Yes};
          G --> H[Request Allowed to Pass];
      end
      H --> I((Internet));
  

---

Axis 2: Operational Parameter Expansion

This section defines the core quarantine technology operating at extreme physical or logical scales.

Derivative 2.1: Quarantine for Nanite Swarms (Nanoscale)

• Enabling Description: In a swarm of collaborative nanorobots (nanites) operating within a medium (e.g., a human bloodstream or industrial lubricant), a central acoustic or radio-frequency controller acts as the NAC. Each nanite must periodically broadcast a valid operational status hash (the "attestation"). If a nanite broadcasts a corrupt hash or fails to report (indicating compromise or malfunction), the controller quarantines it by ceasing to send it operational commands and power. The nanite reverts to a passive, low-power state. "Remediation" is achieved when the controller transmits a high-energy, specific-frequency pulse that either resets the nanite to its factory state or causes it to self-destruct and be filtered out of the medium.

• Diagram:

  stateDiagram-v2
      [*] --> Unverified
      Unverified --> Attesting: Receives Attestation Ping
      Attesting --> Operational: Broadcasts Valid Hash
      Attesting --> Quarantined_Passive: Broadcasts Invalid Hash
      Attesting --> Quarantined_Passive: Timeout (No Broadcast)
      Operational --> Attesting: Receives Attestation Ping
      
      Quarantined_Passive --> Remediating: Receives Reset/Destruct Pulse
      Remediating --> Unverified: Successful Reset
      Remediating --> [*]: Successful Destruct
  

Derivative 2.2: SCADA System Quarantine (Industrial Scale)

• Enabling Description: In a large-scale Industrial Control System (ICS) or SCADA network for a utility grid or factory floor, Programmable Logic Controllers (PLCs) are endpoints. The central SCADA host performs attestation by verifying the running ladder logic hash of each PLC against a master manifest. If a PLC's hash is mismatched (e.g., due to malware like Stuxnet), it is not disconnected. Disconnection could cause catastrophic failure. Instead, it is placed in a "manual-only" quarantine mode. The SCADA host blocks all remote commands to the PLC and alerts human operators that the device requires on-site intervention. The PLC's network port is firewalled to only allow connections from a specific ruggedized laptop used by field technicians for remediation (re-flashing the firmware).

• Diagram:

  flowchart TD
      A[SCADA Host polls PLC-101] --> B{Verify Ladder Logic Hash};
      B -- Matches Manifest --> C[PLC-101 in Auto Mode];
      C --> A;
      B -- Mismatch --> D[PLC-101 Flagged as Compromised];
      D --> E[Place PLC-101 in Manual-Only State];
      D --> F[Block all Remote Commands to PLC-101];
      D --> G[Reconfigure Firewall: Allow only Tech Laptop IP];
      D --> H[Alert Human Operator Console];
  

---

Axis 3: Cross-Domain Application

This section describes how the quarantine mechanism is applied to three unrelated industries.

Derivative 3.1: Aerospace - Modular Avionics Bus

• Enabling Description: On an integrated modular avionics (IMA) bus in a modern aircraft, each Line-Replaceable Unit (LRU) acts as a host. The master Flight Control Computer (FCC) acts as the quarantine authority. When a new or serviced LRU (e.g., a radar altimeter) is connected to the ARINC 664 bus, the FCC challenges it to provide a digitally signed firmware attestation. If the signature is invalid or uses a revoked key, the FCC places the LRU in a "diagnostic-only" quarantine. The LRU is powered, but its operational data is ignored by the FCC, and it is prevented from sending commands to other systems. It can only communicate with the Onboard Maintenance System (OMS) port, allowing a technician to connect and perform remediation.

• Diagram:

  graph TD
      subgraph Aircraft Network
          FCC(Flight Control Computer)
          LRU1(GPS Module - OK)
          LRU2(Radar Altimeter - New/Unverified)
          OMS(Onboard Maintenance System)
  
          LRU2 -- Connects --> FCC
          FCC -- Attestation Request --> LRU2
          LRU2 -- Invalid Signature --> FCC
          FCC -- Place in Diagnostic Mode --> LRU2
          FCC -- Ignore Data From --> LRU2
          style LRU2 fill:#f99,stroke:#333,stroke-width:2px
          
          OMS <-->|Remediation Channel| LRU2
          FCC <-->|Operational Data| LRU1
      end
  

Derivative 3.2: AgTech - Autonomous Tractor Fleet

• Enabling Description: A fleet of autonomous tractors on a smart farm operates on a private 5G network. A central farm management server is the NAC. Before a tractor is allowed to receive a planting or harvesting mission file, it must attest that its GPS, perception (LIDAR/camera), and control software are at the correct patch level. If a tractor fails attestation, it is quarantined. It is locked out of the mission control system but is still permitted to use the network for basic telemetry and to connect to the manufacturer's remote remediation server over a satellite link to download and apply software updates. This prevents a compromised tractor from causing crop damage or colliding with other units.

• Diagram:

  sequenceDiagram
      participant Tractor
      participant FarmServer
      participant Manufacturer
      
      Tractor->>+FarmServer: Request Mission File
      FarmServer->>-Tractor: Request Software Attestation
      Tractor->>+FarmServer: Provide Hashes (Perception, GPS, Control)
      FarmServer->>FarmServer: Compare with Golden Manifest
      alt Hashes Mismatch
          FarmServer-->>Tractor: Deny Mission File (Quarantined)
          FarmServer-->>Tractor: Whitelist access to Manufacturer URL
          Tractor->>+Manufacturer: Download Software Update
          Manufacturer-->>-Tractor: Patch Files
          Tractor->>Tractor: Apply Patch & Reboot
      else Hashes Match
          FarmServer-->>-Tractor: Send Mission File (Operational)
      end
  

---

Axis 4: Integration with Emerging Tech

This section describes integration of the core patent with AI, IoT, and Blockchain.

Derivative 4.1: AI-Driven Behavioral Attestation and Adaptive Quarantine

• Enabling Description: This system replaces static patch-level checking with a dynamic, AI-driven behavioral analysis. A lightweight agent on each endpoint streams telemetry (network connections, process execution, memory usage) to a central AI inference engine. The AI maintains a baseline of normal behavior for each device. If a device's behavior deviates significantly from its baseline (anomaly detection), it is considered to have failed attestation. The quarantine response is adaptive and proportional to the threat score assigned by the AI. A low-score anomaly might result in bandwidth throttling, while a high-score anomaly (e.g., behavior consistent with ransomware) triggers full network isolation, allowing communication only with a forensic analysis server.

• Diagram:

  flowchart TD
      A[Endpoint Telemetry] --> B(AI Anomaly Detection Engine);
      B --> C{Calculate Threat Score};
      C -- Score < 0.2 --> D[No Action];
      C -- 0.2 < Score < 0.7 --> E[Adaptive Quarantine: Throttle Bandwidth];
      C -- Score > 0.7 --> F[Full Quarantine: Isolate Endpoint];
      F --> G[Allow connection ONLY to Forensic Server];
  

Derivative 4.2: Blockchain-Verified Attestation Ledger

• Enabling Description: This method uses a private or permissioned blockchain (e.g., Hyperledger Fabric) as an immutable ledger for security attestations. When a device is patched or passes a security scan, its trusted component generates a hash of its state and writes it as a transaction to the blockchain. The network switch or router acts as a blockchain client. When the device connects, it presents its current state hash. The switch verifies this hash against the latest transaction for that device on the blockchain ledger. If they match, access is granted. If not, access is denied. Remediation requires a new, valid transaction to be posted to the blockchain by a trusted remediation server after the device is cleaned.

• Diagram:

  sequenceDiagram
      participant Endpoint
      participant RemediationServer
      participant BlockchainLedger
      participant NetworkSwitch
      
      RemediationServer->>+Endpoint: Apply Patch
      Endpoint->>Endpoint: Generate New State Hash
      Endpoint->>+BlockchainLedger: Submit New Transaction (State Hash)
      
      loop Connection Attempt
          Endpoint->>+NetworkSwitch: Request Access (presents current hash)
          NetworkSwitch->>+BlockchainLedger: Query Latest Hash for Endpoint
          BlockchainLedger-->>-NetworkSwitch: Return Latest Hash
          NetworkSwitch->>NetworkSwitch: Compare Presented vs Ledger Hash
          alt Hashes Match
              NetworkSwitch-->>-Endpoint: Grant Access
          else Hashes Mismatch
              NetworkSwitch-->>-Endpoint: Deny Access (Quarantine)
          end
      end
  

---

Axis 5: The "Inverse" or Failure Mode

This section describes a version of the invention designed to fail safely or operate in a limited-functionality mode.

Derivative 5.1: "Zero-Trust" Progressive Attenuation Quarantine

• Enabling Description: This is an "assume-breach" implementation. By default, any new device connecting to the network is placed in a highly restrictive "guest" quarantine VLAN. This VLAN provides internet access but blocks all access to internal corporate resources. This is the baseline, fail-safe state. To gain more access, the device must proactively connect to a self-service remediation portal. The portal guides the user through a series of checks (e.g., installing an agent, running a scan, applying updates). With each successful check, the NAC progressively "attenuates" the quarantine, moving the device to VLANs with more privileges (e.g., "Contractor VLAN," then "Employee VLAN," then "Admin VLAN"). This inverts the original model from "quarantine on failure" to "grant privileges on successful attestation."

• Diagram:

  stateDiagram-v2
      [*] --> Guest_VLAN: Device Connects
      Guest_VLAN: Internet Only
      
      Guest_VLAN --> Attesting_Level1: User visits portal, installs agent
      Attesting_Level1 --> Contractor_VLAN: Agent confirms OS patch level
      Contractor_VLAN: Access to shared drives
      
      Contractor_VLAN --> Attesting_Level2: User runs AV scan
      Attesting_Level2 --> Employee_VLAN: AV scan is clean
      Employee_VLAN: Access to internal apps
      
      Employee_VLAN --> Attesting_Level3: MFA with hardware key verified
      Attesting_Level3 --> Admin_VLAN: User is in Admin group
      Admin_VLAN: Full access
  

---

Combination Prior Art with Open-Source Standards

1. Combination with SPIFFE/SPIRE (Cloud-Native)

• Enabling Description: The quarantine method of US patent 9,516,048 is integrated into a cloud-native environment using the SPIFFE and SPIRE standards for workload identity. A custom SPIRE Node Agent includes a "cleanliness attestor" plugin. Before issuing a SPIFFE Verifiable Identity Document (SVID) to a workload (e.g., a Kubernetes pod), the attestor plugin checks the container image hash against a known-good registry and verifies the host kernel version. If attestation fails, the SPIRE server issues an SVID with a very short TTL and a special "quarantined" identity field. A network policy controller (e.g., Calico) reads this SVID and enforces a network policy that only allows the pod to communicate with the corporate image registry and a security scanning service for remediation.

2. Combination with Matter (Smart Home IoT)

• Enabling Description: The patent's quarantine logic is applied to the Matter smart home standard. The Matter Controller (e.g., a smart speaker) acts as the NAC. When a new Matter device (e.g., a smart lock) tries to join the fabric, the Controller initiates the standard commissioning flow but adds a custom attestation step. It challenges the device to provide its signed firmware version. If the firmware is outdated or from a non-certified vendor, the Controller places the device in a "commissioning-only" quarantine. The device is part of the fabric for administrative purposes but is blocked from all operational clusters (e.g., the Door Lock Cluster). The user is notified via the Controller's app, which provides a link to the manufacturer's remediation (firmware update) page.

3. Combination with FIDO2/WebAuthn (User/Device Authentication)

• Enabling Description: The attestation and quarantine process is tied to user login using the FIDO2/WebAuthn standard. When a user logs into a web resource via a corporate portal, the portal initiates a WebAuthn ceremony. The browser prompts the client OS's FIDO platform authenticator (which is backed by a TPM or Secure Enclave). The client-side agent adds the machine's patch/cleanliness status as a signed assertion extension to the WebAuthn ceremony. The server validates both the user's presence (via FIDO2) and the machine's health. If the health attestation fails, the user is authenticated but their session is immediately redirected to a quarantine server which provides remediation instructions, blocking access to the originally requested resource.