Procedures for keys known or suspected to be compromised cover the five elements below. In particular: components or shares are not reloaded when the original key or the SCD may be compromised; when unauthorised alteration is suspected, the SCD is inspected and shown to be free of unauthorised change before any new key goes in; a key known to be compromised is replaced, a suspected compromise is assessed and documented and the key replaced if it is confirmed, every key that was encrypted under the compromised key, or that was derived from it, is replaced as quickly as feasible, the new key is neither a variant nor a transformation of the old, and the compromised key is never used to deliver its successor; known or suspected substitution is handled in the same way; a documented escalation process informs every organisation that shares or once shared the key, names key personnel, assesses the damage (with outside help where required) and sets the actions for software, hardware, keys and encrypted data; the events that can signal compromise are defined and include missing SCDs, tamper-evident seals or envelope numbers or times that do not match the logs, seals or envelopes that have been opened or attacked, signs of unauthorised physical or logical access, and any gap in the record showing a key was held under dual control and split knowledge from creation.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.