# If you can't run this yourself — what to ask your integrator or Rockwell reseller

**What this is:** every test in this repo requires running Python scripts. Not every utility has
someone who can do that, and that's fine — the point isn't that you personally run the code, it's
that these are now answerable questions instead of open ones. Hand this page to whoever supports
your PLC (an integrator, a Rockwell reseller, in-house IT/OT staff) and ask them to answer each line.

## Before anything else

- [ ] **Is our PLC reachable from the internet right now?** (Phase 0 — this should be "no,"
  unconditionally, regardless of anything below.)
- [ ] **Do we have an inventory of every Logix-family device, its firmware version, and whether it's
  ever been internet-reachable?** (`PHASE0_INVENTORY_WORKSHEET.md`)

## Does our hardware support the real fix (Phase 3)?

- [ ] **Does our specific PLC firmware version support CIP Security?** Hardware-gated — legacy
  Logix often does not. This is a yes/no your integrator or Rockwell rep can answer directly.
- [ ] **If yes: when CIP Security is enabled, does the controller reject a connection using another
  device's certificate — not just any CA-signed certificate?** This is the actual test
  (`test3_mutual_tls_fix.py`, case 3 vs. case 4) — ask to be shown a rejection, not just told it works.
- [ ] **Is revocation configured** (CRL, OCSP, or short-lived certs), so a compromised or offboarded
  credential can actually be recalled? (`test4_revocation.py` is what this question is modeled on.)
  **And what happens if the revocation source can't be reached** — does the system lock everyone
  out (fail-closed) or let everyone in (fail-open)? Someone should be able to answer this, on
  purpose — see `PHASED_ROLLOUT.md` Phase 3 for the trade-off and a default recommendation.
- [ ] **If CIP Security is going on, what happens to the write-monitoring alerter from Phase 2?**
  Encryption blinds it. Confirm what replaces the visibility rather than assuming it still works.
- [ ] **When an engineer leaves or a device is replaced, is there an actual process to issue a new
  credential AND separately retire the old one** — not just an assumption that issuing the new one
  handles it? Re-issuing alone does not revoke anything (`test5_rotation.py` is what this question
  is modeled on) — ask to see both steps happen, not just the first.

## If our hardware can't do CIP Security (Phases 1–2, the durable fallback)

- [ ] **Is the PLC on its own segment, behind a firewall, allowlisting only the specific traffic it
  needs?** Phase 1 — Rockwell's own CPwE guide, cited in `PHASED_ROLLOUT.md`, is the reference.
- [ ] **Is there any monitoring that would flag an unexpected write to a control tag?** Phase 2 —
  this doesn't require new hardware to have an answer; ask what's already watching.

## The honest bottom line

None of these questions require understanding cryptography. They require someone who supports your
system to give a straight yes / no / unknown for each line — and "unknown" is a fine answer, it just
means it's the next thing to find out, not a failure.

---
*l0gic — Patrick Crosby, 2026-08-03. DRAFT — not committed, not pushed; holding for review.*