The Dependencies and Identities a Factory Must Trust
This chapter focuses on the part of manufacturing recovery that a clean storage copy cannot solve by itself: identifying what must exist together for a production mission to work, and deciding which identities and management paths are trustworthy enough to operate it. The useful outcome is a mission-specific dependency graph—not a longer inventory of assets—and a clear distinction between a system that can be reached and one that can safely authorize recovery.
From an asset inventory to a mission graph
An asset inventory asks what an organization owns or operates. It may list storage systems, servers, applications, workstations, network equipment, and production devices. That information is necessary, but it answers the wrong question for a constrained restart. The recovery team needs to know what must work together to produce a defined output, what state crosses each interface, and who is responsible for deciding whether that state is usable.
A mission-specific dependency graph starts at the production result and works backward. Suppose a plant wants to resume one product family on one line for a limited period. The graph begins with the output that must be made and released. It then asks what quality checks and records make that release valid, what scheduling and recipe information make the work executable, which identities allow operators and engineers to use those systems, and which network paths connect the applications to the physical process. It continues outward to materials, logistics, suppliers, customers, and the people and procedures that stand in for unavailable services.
This direction matters because an outage list follows the shape of the technology, while a production mission follows the shape of the work. An outage list might say that a manufacturing execution system, a historian, and an identity service are affected. A mission graph asks what each one contributes. The execution system may coordinate orders and schedules. The historian may provide process visibility or records needed to understand the run. The identity service may determine whether operators, service accounts, and administrators can be distinguished and authorized. If the mission depends on all three, restoring one does not restore the mission.
The graph also exposes hidden dependencies that are easy to omit when teams focus on major applications. Time synchronization can determine whether events from different systems can be correlated. Certificates and keys can determine whether a service can authenticate or decrypt what it needs. Configuration and access-control information can determine which host can see which storage resource. An engineering workstation can be the path through which a recovered application interacts with controllers. These are not decorative details. They are interfaces across which state, authority, and evidence move.
Each edge in the graph should raise a state question. Is the relationship available? Is it trustworthy? Is there evidence for that judgment? Is the relationship approved for the proposed operating condition? For example, it is not enough to draw a line between a scheduling application and an identity service. The recovery team must know whether the application can authenticate, whether the account used for the connection was exposed, whether the configuration matches the intended line, and who can authorize the connection. The graph becomes useful when its relationships carry these questions instead of functioning as a static picture.
The same reasoning applies to data consistency. A production application may be restored with a valid-looking database, but if the associated recipes, order data, quality records, or configuration were recovered from incompatible points in time, the application can produce a coherent screen and an incoherent operation. NIST’s storage guidance therefore treats application and business-process consistency as a recovery concern, not only a database concern. The precise set of data and services varies by plant, but the dependency principle does not: the mission requires a compatible set, not a collection of individually successful restores.
People and procedures belong in the graph because they own decisions that software cannot make on its own. Someone must decide which product or line is in scope, approve a safe operating envelope, validate a quality result, authorize a connection, and determine when a degraded workaround must stop. A manual step is not the absence of a dependency. It is a dependency whose state is carried by people, documents, communication, and authority rather than by an automated service.
External relationships are part of the same system. A supplier may need to confirm material availability. A logistics provider may need to accept a shipment. A customer may need a reliable commitment, and a vendor may control a maintenance or remote-access path. The manufacturing review describes supplier dependency failure as a recovery mode because a plant can restore internal systems and still lack the external coordination required to receive inputs or release outputs. The graph should cross the organizational boundary when the production mission does.
The result is not a universal architecture diagram. It is a question-driven model of one mission under one compromise state. A different product, line, or duration can require a different graph. That flexibility is a strength: it keeps recovery decisions tied to what the plant is actually trying to resume instead of assuming that the most important assets are the same as the most important production relationships.
The important feature of this graph is not the names of the boxes. It is the direction of the relationships. The mission requires scheduling, quality, OT, materials, and logistics; those elements in turn require identities, operators, engineering paths, suppliers, and customers. If a relationship is missing, the team should be able to say whether the mission can use an approved substitute or whether production must wait.
Reachable identities are not necessarily trusted identities
Identity is often treated as a background service: if the directory responds and a user can log in, the system appears to be functioning. After ransomware, that assumption is unsafe. The manufacturing review calls the failure identity trust collapse because the problem can include directory services, privileged and service accounts, tokens, remote administration, vendor access, and administrative workstations. A recovered application may be reachable while the credentials used to operate it remain compromised.
The distinction is easier to see if identity is treated as part of the control path. An operator identity answers who may use a system. An administrator identity can change its configuration. A service account may connect applications or move data without a person at a keyboard. A vendor connection may cross organizational boundaries. If any of those paths were exposed during the incident, restoring the target application does not restore confidence in the decisions made through it.
There is also a timing problem. A credential may have been stolen before encryption, while the visible disruption happened later. A service account may continue to work after its owner has lost confidence in it. A remote administration path may be technically disabled in one place but remain available through another shared service. The sources do not provide a universal way to determine the compromise window for every environment, but they do support the reason for asking: trust cannot be inferred from the fact that authentication still succeeds.
This is why an identity-clean-room idea is useful in recovery reasoning. Before production systems are trusted, responders need validated administrative accounts, reset credentials, trusted privileged workstations, and controlled access paths. Resetting a password alone may not be enough if the workstation used to reset it is compromised, if a service account still carries excessive authority, or if an external vendor path remains open. The clean-room idea is not a single universal procedure. It is a boundary that prevents the recovery team from reusing identity state merely because rebuilding it is inconvenient.
Management systems deserve the same attention. NIST recommends separating data-protection configuration management from the data-consumption plane so that servers and clients cannot simply change their own backup, replication, or point-in-time-copy configuration. It also recommends that cyber-attack recovery systems use designated management environments and credentials that are not available through normal production administration. The underlying principle is separation of authority: the system being protected should not be able to silently redefine the protection it is supposed to rely on.
Logs provide another part of that authority and trust picture. Storage systems can record password changes, account and privilege changes, configuration changes, access attempts, system restarts, and other events relevant to an investigation. If those records remain only on the device that an attacker can alter or destroy, the recovery team may not be able to reconstruct what happened. NIST therefore recommends centralized or external logging, reliable delivery, a common time source, protected retention, and appropriate controls for evidentiary integrity.
Accurate time is not a minor administrative convenience in this context. Events from storage, identity, applications, and OT have to be placed in relation to one another. If timestamps cannot be correlated, responders may not know whether a backup preceded compromise, whether a credential was used before or after a configuration change, or whether a restored system behaved as expected. Time does not prove that a system is clean, but unreliable time can remove evidence needed to make the judgment.
A protected log is useful only if its contents are complete enough for the decision at hand. The recovery team may need to connect a change in privileges to a storage configuration event, an access attempt to a restore operation, or a service restart to a loss of visibility. This does not mean every event must become a narrative. It means the logging policy and retention design should reflect the fact that recovery may depend on reconstructing relationships across systems, not merely proving that a log file exists.
This is the practical meaning of proof-of-recovery. It is not a mathematical proof and not formal safety certification. It is an auditable bundle that records the restore source, compromise assessment, identity state, configuration validation, dependency consistency, test results, OT or operational approval, monitoring plan, and residual risk. The bundle lets technical responders, operations managers, safety stakeholders, and auditors examine why a restart was considered defensible.
The distinction among availability, trust, and evidence prevents several category errors. A service can be available but untrusted because its credentials or code may be compromised. It can be trusted in isolation but unsupported by evidence strong enough to justify production use. It can have good evidence and still lack an approved operating state. These are not competing labels for the same condition; they are different properties that a mission dependency must satisfy.
The dependency graph also clarifies why external parties and human procedures cannot be added at the end as “business considerations.” If a supplier confirmation is required to know that material is valid, or if an operator’s manual sign-off is required before output can be released, that relationship belongs in the production mission from the start. A factory is not minimally viable if it can run a machine but cannot establish that the input, process, and output are authorized and usable.
At this point, recovery has two complementary models. The storage model asks whether a copy is complete, clean enough, independent, and restorable. The mission model asks which systems, identities, people, procedures, and external relationships must work together. The next decision is to put those models under pressure: compare a plan that restores convenient assets quickly with one that takes longer to establish copy trust, dependency completeness, identity integrity, and evidence. Before anything is reconnected to live production, the team must be able to say not only what is back, but what it can actually prove.