About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A trust boundary is a place where you stop believing a request just because it arrived. Before the incident, those places were your directories, your administration tools, your network segments, and the backup path that was allowed to write. The incident is evidence that at least one of them was wrong, or that a legitimate path was used by someone else. Recovery does not inherit the old map. It draws a smaller one and widens it on purpose.
NIST SP 800-184 says an organisation should understand system boundaries, trust relationships, and identities, because without that it is hard to be confident a recovery worked. The example is direct: if a directory is recovered and the adversary still has an account that can manage it, the adversary remains. The same paragraph lists a privileged service account, a forgotten administrative account, a management tool with agents still installed, and a public-key component used for authentication. Later, the guide's procedures include restoring from clean backups or rebuilding, enhancing the identity system and the trust boundary, replacing compromised files, patching, changing passwords, and tightening the perimeter. In the fictional breach scenario, the stated goal is to re-instantiate trust in an order taken from the dependency map, starting at infrastructure and moving up to applications, while remediating the credential store, user accounts, and tokens, and tightening the flows that were involved. The security team signs that rebuilt servers meet the required posture before network operations are restored and services are made available. Business owners then test against the agreed service levels before anything is made public.
NIST SP 800-61 Rev. 3 describes recovery as restoring from clean backups, rebuilding, replacing compromised files, patching, changing passwords, and tightening controls. Where the actor is sophisticated and the methods are not fully known, it says recovery may go as far as replacing hardware. The September 2023 #StopRansomware Guide says to put only clean systems on a recovery VLAN, to reset passwords for affected accounts once the environment is cleaned and rebuilt, and to update customer-managed keys as needed. Its preventive section describes a zero-trust approach as assuming the network is compromised and enforcing least privilege on each request. That is a design stance, not a product you switch on at the end of a weekend.
This article draws the boundaries. It does not perform an authoritative directory restore, and it does not repair an operating system.
What you are re-drawing
Four boundaries move independently. Restoring a disk does not reset any of them.
Who may administer. The daily directory admins, the backup operators, the hypervisor admins, and the remote-support tool are the accounts SP 800-184 is warning you about. IR 8374r1 ties ransomware to credential compromise and to separation of duties. After a clean-room restore, administration of the recovered systems starts from the break-glass identities you planned, not from the groups that existed on the copy. A copy of a directory is a copy of the attacker's accounts if the point is late, and it is a copy of stale privileged groups even if the point is early. Early is better. It is not automatically minimal. Unrecognised privileged access needs investigation and a controlled containment or remediation decision before the directory is trusted; unfamiliar accounts are not automatically malicious, and indiscriminate deletion can break recovery dependencies.
Which network may speak. CISA's recovery VLAN rule is a boundary: membership is "clean systems only". Production, the holding segment, and the old remote-access concentrators stay on the other side until a named change adds a flow. SP 800-184's scenario talks about restricting network access and tightening flows between the components that were involved, without pretending the business can stay stopped forever. Each new flow is a boundary change. It has an owner, a reason, and a review. A restored server that can reach everything it could reach last month has been given the old boundary back, which is the boundary that failed.
Which identity is authoritative. For a while the clean room may have local accounts and a directory you have classified. Production may still have the old directory, or a directory you do not yet trust. The dangerous moment is the join. Joining a staged system to a directory that still contains the intruder undoes the staging gate. SP 800-61 Rev. 3 puts password changes and tighter controls inside recovery for that reason. The order is: the directory you will trust is itself a restored or rebuilt system that has passed its own gate; compromised accounts are contained promptly under the incident plan, with final credential replacement coordinated after clean-up and rebuild; only then do other systems take tickets from it. This is a sequencing boundary. The commands that implement a directory restore belong to a directory procedure this article does not contain.
Which tools may return. Management agents, backup agents, remote support, and "temporary" administration shares are trust relationships with vendors and with your own past. SP 800-184 names the agent that remains installed as a persistence path. CISA names unexpected remote-management software as a hunt sign. The boundary decision is a list: tools allowed on the recovery segment, tools forbidden until a later phase, and tools retired because they were the intruder's method. An empty list is not realistic. An unexamined return of every agent in the old image is how the intruder is invited back in a signed binary.
Our recommendation, not a control number: write the four lists before the first production join, even if the lists are short. A system with no written administration boundary will be administered by whoever still has a password that works.
Order, from the dependency map
SP 800-184's fictional team restores in an order dictated by dependencies, infrastructure before applications. That is the right shape for boundaries as well. You cannot tighten application flows you have not yet placed, and you should not place applications on infrastructure whose administrators are still the old group.
A planning order, not a run that was executed:
- Establish the minimum recovery network, trusted time, name resolution, storage and local administration needed to bootstrap identity, with owners for each. Authentication and certificate checks are meaningless without the clock, and the segment is the boundary everything else sits inside.
- The identity system you intend to trust is staged, checked, and reduced to accounts you can explain. Credential stores and tokens are in this step because the scenario puts them there, not because a particular directory product is assumed.
- Expand the minimal bootstrap services into the infrastructure applications require, using explicit flows and verified dependencies. Each flow's absence is the default.
- Applications follow, still on the recovery segment, and owners test them there. SP 800-184 has business owners and analysts do acceptance testing before a service is made publicly accessible. SP 800-61 Rev. 3's RC.RP-04 is the same idea: owners confirm the service, and you watch whether it performs.
- Production routes, remote access, and the old management tools are a separate authorisation. The security sign-off in the SP 800-184 scenario comes before network operations are restored. Treat that sign-off as a boundary change, with the staging record attached.
- Re-establish a trusted backup path before restored services generate important new data, or explicitly accept and time-limit the protection gap. Recovery also needs an approved source-read path earlier; neither path must reuse the compromised console. A backup agent pointed at the old console, with the old credential, can write a "good" backup of a re-infected server or let the old console push a job back. The path returns when the copy destination and the credential have both been through the same trust decision as the servers. If a safe destination is not yet available, leadership must decide which writes to defer and how to protect essential new work. The guidance does not prescribe backups as the last service in every recovery.
CISA's zero-trust paragraph is useful here as a test, not as an architecture project you will finish during the incident. For each request you are about to allow, name the identity, the device, and the reason. If the reason is "that is how it worked in the image", you have not drawn a boundary. You have photocopied one.
What "clean" does not transfer
A system can pass staging and still be the wrong neighbour.
- Hardware and the hypervisor sit under the guest boundary. SP 800-61 Rev. 3's note on replacing hardware when methods are unknown is a boundary question: do you trust the platform the clean guest will run on? If you do not, the guest's pass does not promote the host. Escalate that decision. Do not bury it.
- A directory join introduces authentication and administrative dependencies; it does not establish that the joining host is clean. One early join of an unstaged workstation reopens the problem SP 800-184 described. Membership has a gate.
- Shared services, such as a file server or a management database used by many applications, are boundaries of their own. Restoring one application onto a shared service you have not classified shares the application's fate with everything else on that service.
- People are a boundary. SP 800-61 Rev. 3 includes human resources when an employee may have caused an incident, and it includes facilities because physical access and logical access meet. A returned administrator badge, a returned laptop, and a returned VPN token are boundary changes. They wait for the same named authority as a firewall change.
- Customers and other organisations were trusting your old boundary too. SP 800-184 puts notification with legal and public affairs, and it includes the case where you cannot meet an objective and may need to send people to an alternate service you arranged in advance. The trust you tell them you have re-established should match the lists you actually drew. A status page that says "systems are restored" while the old remote-access path is open is a false boundary.
Hypothetical: the finance application passes staging on the recovery segment. Someone joins it to the production directory so users can sign in, because the directory "was restored yesterday". That directory restore used a point from after the first rogue privileged account, and the reset list has not been finished. The application is no longer inside the boundary you tested. The response is coordinated re-isolation and investigation of what the exposed directory could have changed. Undoing the join alone does not undo new persistence or credential exposure; the application and identity system both need reassessment.
Risks and limits
- Drawing a boundary and enforcing it are different. This article does not provide firewall, directory, or agent commands. Those belong in procedures you have tested. SP 800-184 warns against shortcuts during execution of the procedures you did define.
- A very tight boundary can stop the business longer than the leadership will accept. SP 800-184 expects a workaround and a conversation with managers when an objective will not be met. Record the flows you opened early, and review them. An emergency flow with no review becomes the new design.
- Zero trust, as the CISA guide uses the term, is a set of ideas about per-request decisions. Implementing a full architecture is not a recovery weekend, and this article does not claim one.
- No environment was rebuilt here. The order is a reading of SP 800-184's dependency sequence and of the CISA membership rule.
- Directory-forest procedures, including authoritative restores, are a different speciality. Nothing here is a substitute for them.
Research and verification
This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.
Sources
Independently reopened 13 November 2026.
- NIST SP 800-184 (December 2016).
- NIST SP 800-61 Rev. 3 (April 2025).
- NIST IR 8374r1 (June 2026).
- CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
This article was originally published on .