Can Remedy isolate an unknown device?
The architecture includes restricted admission and adaptive quarantine. A complete production enforcement and release workflow has not been established in the reviewed product evidence.
AI Defence / Remedy architecture
Adaptive Network Trust applies Remedy’s measured-trust architecture to devices and connections. The intended decision combines enrolled identity, current posture, authenticated context and expected behaviour before granting the network access a task needs.
An IP address can change. Several devices may share a public address through NAT. MAC addresses can change, be randomised or be spoofed. These observations are useful context, but do not independently establish the identity or health of a device.
Stronger evidence can include an enrolled device certificate, hardware-backed identity or TPM attestation where available, a current posture report and an authenticated session. Network context adds VLAN/subnet, DHCP observations, expected services and history. Attestation coverage depends on the device, operating system and supported integration.
A recognised device with current posture in an expected context can receive policy-scoped access. A new device, certificate change or posture failure needs a restricted decision while the uncertainty is resolved. A revoked or demonstrably hostile device may be denied or isolated.
An address change alone may be ordinary work on a different network. Combined with a new device identity, failed posture, repeated authentication failure and unusual peer access, it deserves a different assessment. Correlation should preserve the evidence and uncertainty behind the decision.
Quarantine is a restricted network state with an explicit purpose. It may permit only the paths needed for enrolment, authentication, essential DNS/DHCP, Remedy communication, updates and remediation. Those allowed paths must themselves be bounded and protected.
Access to peer workstations, SMB shares, databases, management interfaces and backups is withheld unless the policy specifically requires it. Quarantine is not simply disconnecting everything and losing the ability to repair the device. The design needs a retained management path, a clear operator view and a tested release procedure.
| Device state | Intended access | Next evidence required |
|---|---|---|
| Recognised and expected | Resources required by role and task | Continuing identity, posture and context checks |
| New or materially changed | Enrolment or remediation paths only | Identity, posture and policy re-evaluation |
| Hostile or revoked | Deny or isolate within enforcement scope | Incident investigation and authorised recovery |
After one endpoint is compromised, an attacker may try to reach other workstations, file servers, administrative services, databases or backup systems. This movement across the estate is often called east-west traffic. Restricting unnecessary connectivity can limit the consequences of the first compromise.
A workstation with no business reason to contact hundreds of peers should not automatically have that authority. Unexpected peer discovery or management connections can contribute to a trust downgrade and investigation. This is a defensive policy concept; detection coverage and enforcement depend on the controls deployed at each boundary.
The intended sequence is a material change or risk signal, reduced trust, restricted access, authorised remediation, renewed attestation, verification and then scoped recertification. A successful MFA prompt does not by itself establish that the endpoint is healthy.
Restoring connectivity is an access decision; restoring data and confirming security are separate steps. If required evidence is missing, stale, contradictory or inconclusive, it must remain visible. Recovery should not silently clear the reason the device was restricted.
The design can use appropriate enforcement points such as firewalls, identity-aware access gateways and network access control systems. It should not create an unnecessary replacement for every customer network component. Actual connector support and action permissions require a confirmed deployment plan.
Network Trust, adaptive quarantine and the integrated recertification workflow are planned architecture. The reviewed network production validation capability is unavailable. Evaluate supported device classes, unmanaged devices, IPv4/IPv6 paths, segmentation coverage and safe failure behaviour before relying on a pilot.
The architecture includes restricted admission and adaptive quarantine. A complete production enforcement and release workflow has not been established in the reviewed product evidence.
The design uses multiple independent signals. An address is context; a change should be assessed with device identity, posture, user session, task and risk.
No. Quarantine restricts connectivity. Investigation, remediation, recovery and verification are separate responsibilities before normal access is restored.
Talk directly to Altari
Discuss a demonstration, current capabilities and a bounded evaluation with Altari Systems.