{
 "slug": "cryptographic-two-person-control",
 "topic_id": "TOPIC-134",
 "cluster": "Electric Grid, Water & OT Identity",
 "tier": "Tier B",
 "title": "Two-person control that software cannot prove",
 "summary": "Two-person control is a physical concept: two keys, two humans, two locks. Digitised into a workflow with two approver fields, its independence is asserted by procedure rather than enforced by construction.",
 "lede": "Two-person control has an unusually clean physical definition. Two locks, two keys held by two people, and a mechanism that will not operate unless both are turned. Nothing about that definition survives being implemented as two rows in a database.",
 "date": "2023-12-17",
 "category": "Vertical",
 "author_id": "constance-ibe-whitmore",
 "tags": [
  "two-person control",
  "nuclear cyber security",
  "10 CFR 73.54",
  "dual approval",
  "safety systems",
  "digital assets"
 ],
 "image": "https://cdn.twc.sh/images/igcache/Two%20Person%20Control/1200_630/blog.jpg",
 "schema": "Article",
 "key_takeaways": [
  "A workflow with two approver fields can be completed from one workstation, in one session, by one person holding two credential sets.",
  "Cryptographic two-person control specifies four constraints: distinct credential, distinct authenticator model, distinct device, bounded window, over an identical canonical statement.",
  "The test is simple and most organisations have never run it: can your dual-approval workflow be completed end to end from a single device?"
 ],
 "body": [
  {
   "type": "h2",
   "text": "What the regulation requires and what it leaves open"
  },
  {
   "type": "diagram",
   "kind": "compare",
   "alt": "The physical control and its software translation",
   "caption": [],
   "nodes": "The physical version enforces independence through geometry. The software version asserts it.",
   "left": {
    "title": "Two keys, two locks",
    "items": [
     "Physically separated",
     "Simultaneous action required",
     "One person cannot reach both",
     "Independence is structural"
    ]
   },
   "right": {
    "title": "Two approver fields",
    "items": [
     "Same system, same database",
     "Sequential clicks",
     "One session can hold both",
     "Independence is assumed"
    ]
   }
  },
  {
   "type": "p",
   "html": "Under 10 CFR 73.54, licensees shall provide high assurance that digital computer and communication systems and networks associated with safety, security and emergency preparedness functions are adequately protected against cyber attacks. Regulatory guidance elaborates the programme elements, including access control and the use of two-person rules for certain activities."
  },
  {
   "type": "p",
   "html": "The regulation does not, and arguably should not, specify the cryptographic properties of a two-person control implemented in software. That leaves a gap between the concept as understood — two independent humans — and the implementation as built — two approval records."
  },
  {
   "type": "h2",
   "text": "The test that exposes the gap"
  },
  {
   "type": "p",
   "html": "One question, answerable in an afternoon by anyone with access to a test environment."
  },
  {
   "type": "blockquote",
   "text": "Can one person, sitting at one workstation, holding two sets of credentials, complete a dual-approval workflow end to end?"
  },
  {
   "type": "p",
   "html": "In most implementations the answer is yes, and it is yes by design, because the workflow engine models approval as a state transition with an approver attribute and has no concept of a physical device."
  },
  {
   "type": "p",
   "html": "That does not mean anyone is doing it. It means nothing prevents it, nothing detects it, and the record produced is identical either way — which is the definition of a control that cannot be evidenced."
  },
  {
   "type": "h2",
   "text": "Four constraints that restore the property"
  },
  {
   "type": "table",
   "head": [
    "Constraint",
    "Enforced by",
    "What it prevents"
   ],
   "rows": [
    [
     "Distinct credential",
     "Verifier rejects a second assertion from the same credential",
     "One person approving twice"
    ],
    [
     "Distinct authenticator model",
     "Authenticator attestation identifier must differ",
     "Both approvals from one shared hardware token or reader"
    ],
    [
     "Distinct device binding",
     "Credential provenance differs",
     "Both approvals from one workstation"
    ],
    [
     "Bounded window",
     "Second assertion within a defined interval",
     "Retrospective second approval assembled after the fact"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The second constraint does the most work and is the least obvious. Authenticator attestation — the identifier that says which model of authenticator produced an assertion — lets a verifier distinguish two credentials on one device from two credentials on two devices. Without it, distinct credentials can still mean one physical person."
  },
  {
   "type": "h2",
   "text": "Where this applies in a digitised plant"
  },
  {
   "type": "p",
   "html": "Digital upgrades have moved several historically physical two-person controls into software. The candidates worth examining:"
  },
  {
   "type": "ol",
   "items": [
    "Changes to setpoints or logic in systems supporting safety or important-to-safety functions.",
    "Removal or bypass of a protective function for maintenance.",
    "Introduction of media or software into a protected digital asset.",
    "Modification of access permissions for critical digital assets.",
    "Disabling or modifying security monitoring on a protected system."
   ]
  },
  {
   "type": "p",
   "html": "Each of these had a physical two-person analogue that digitisation quietly dissolved, usually without anyone deciding to dissolve it."
  },
  {
   "type": "h2",
   "text": "Deployment realities in an isolated environment"
  },
  {
   "type": "p",
   "html": "Plant networks are isolated by design, which rules out any control that depends on reaching an external service. Verification must be offline against a published key held locally, with key distribution handled as a configuration task through the existing controlled process."
  },
  {
   "type": "p",
   "html": "Credential enrolment has to accommodate the reality that staff move between areas with different device policies. Enrol at least two authenticators per person, and expect the first month of data to reveal more about your device provisioning than about your staff."
  },
  {
   "type": "h2",
   "text": "What to bring to the corrective action programme"
  },
  {
   "type": "p",
   "html": "Frame it as a design-assurance observation rather than a finding. The workflow implements a procedural control whose defining property — independence — is not enforceable by the implementation and not demonstrable from the record. That is a clean, factual statement, it is verifiable by the single test above, and it does not require anyone to have done anything wrong."
  },
  {
   "type": "p",
   "html": "It also has an unusually cheap remediation, which is the part that gets it prioritised: four constraints on the second assertion, no change to the workflow steps."
  },
  {
   "type": "h2",
   "text": "What would have to be true"
  },
  {
   "type": "table",
   "caption": "Four properties, and how to establish each",
   "head": [
    "Property",
    "How to establish"
   ],
   "rows": [
    [
     "Two distinct humans",
     "Distinct enrolled credentials"
    ],
    [
     "Two distinct devices",
     "Authenticator attestation showing separate hardware"
    ],
    [
     "Neither can act alone",
     "Both signatures required at the point of effect"
    ],
    [
     "<strong style=\"font-weight:600\">Independent judgement</strong>",
     "<strong style=\"font-weight:600\">Workflow design — cryptography cannot supply this</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The last row deserves emphasis because it is frequently over-claimed. Distinctness is provable; independent thought is not. What a second rendering can do is present the act differently to the second approver, so they are evaluating rather than confirming."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Our system enforces different user IDs.”</strong> Which prevents the same account approving twice. It does not prevent one person holding two accounts, or one attacker holding two sessions."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Attestation is intrusive.”</strong> Model-level attestation identifies a product line, not a device or a person. It is the minimum needed to show two separate authenticators and it reveals nothing about either holder."
  }
 ],
 "faq": [
  {
   "q": "Does NRC require cryptographic independence?",
   "a": "No. Regulation and guidance describe programme elements and the use of two-person rules. The cryptographic constraints proposed here exceed the requirement and are offered as a design improvement."
  },
  {
   "q": "Will this work on an isolated plant network?",
   "a": "Yes. Verification is offline against a locally held published key, with no external dependency."
  },
  {
   "q": "What if two approvers genuinely share a workstation?",
   "a": "The distinct-device constraint fails and the record shows it. That is the correct outcome — the approval still happened, and the record accurately describes the conditions."
  },
  {
   "q": "How is this different from requiring two logins?",
   "a": "Two logins can be performed by one person in sequence. Authenticator attestation is what distinguishes two people from one person with two credentials."
  },
  {
   "q": "Does cryptography make two approvers think independently?",
   "a": "No. It establishes distinct humans, distinct devices and integrity of the approved payload. Independent judgement is a workflow design problem."
  },
  {
   "q": "Why does distinctness attestation matter?",
   "a": "Because synced credentials can put two valid signatures in one person's hands, which defeats the control silently."
  },
  {
   "q": "What is the cheapest improvement?",
   "a": "Rendering the act differently for the second approver, so they evaluate rather than confirm the first."
  }
 ],
 "sources": [
  {
   "t": "10 CFR 73.54 — protection of digital computer and communication systems and networks."
  },
  {
   "t": "Bureau of Industry and Security — Export Administration Regulations",
   "u": "https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear"
  },
  {
   "t": "FIDO Alliance specifications",
   "u": "https://fidoalliance.org/specifications/"
  },
  {
   "t": "Published practice on two-person control in high-consequence industries."
  },
  {
   "t": "NIST SP 800-53 Rev. 5 — separation of duties",
   "u": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"
  }
 ],
 "related": [
  {
   "slug": "independent-double-check-proof",
   "title": "The independent double-check that isn't",
   "category": "Developer"
  },
  {
   "slug": "provable-break-glass",
   "title": "Break-glass in the enterprise",
   "category": "Compliance"
  },
  {
   "slug": "sod-exception-evidence",
   "title": "Segregation of duties exceptions",
   "category": "Compliance"
  }
 ],
 "wordcount": 962,
 "url": "/blog/cryptographic-two-person-control.html",
 "reading_time": "4 min read",
 "image_title": "Two Person Control",
 "meta_description": "Two-person control is a physical idea: two keys, two humans. Digitised into two approver fields in a workflow, its independence is only assumed.",
 "hub": {
  "slug": "topics/ot-identity",
  "title": "Grid, water and OT identity"
 },
 "answer": "Not as usually implemented. Two-person control is a physical concept — two keys, two humans, two locks — and digitising it into a workflow with two approver fields makes its central property, independence, an assumption rather than a fact.",
 "answer_q": "Can software prove two-person control?",
 "glossary": [
  {
   "term": "Two-person control",
   "def": "A requirement that two people act together, whose value rests entirely on their independence."
  },
  {
   "term": "Authenticator attestation",
   "def": "Evidence about the authenticator model, usable to show two signatures came from separate hardware."
  },
  {
   "term": "Synced credential",
   "def": "A credential replicated across a user's devices, which can place two credentials in one person's hands."
  }
 ],
 "checklist": {
  "title": "Making two-person control real",
  "id": "twoperson",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Require two distinct enrolled credentials.",
    "text": "Not two accounts."
   },
   {
    "name": "Verify authenticator distinctness.",
    "text": "So synced credentials in one person's hands do not count as two."
   },
   {
    "name": "Bind both to the same payload digest.",
    "text": "So an edit between approvals invalidates the first."
   },
   {
    "name": "Render differently for the second approver.",
    "text": "So they evaluate rather than confirm."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds the operator to the exact command, session or two-person act, verifiable offline at the console or the gateway — which is the condition OT and field work actually run in.",
  "href": "../docs.html",
  "label": "See offline verification"
 }
}