Skip to content

Notes

Cybersecurity decisions, made legible

Original briefings for people deciding what to build, buy, fund or govern. Each note connects a technical question to its operating consequence while keeping evidence and claim boundaries in view.

This is a working decision library—not a journal, a copy of internal research or a catalogue of deployments.

Published notes

A compact reading list

10 entries

  1. Entry 1

    Executive briefing

    Post-quantum identity: five decisions before procurement

    A credible transition begins with the trust paths an institution must preserve—not with an algorithm name on a product sheet. Five decisions help turn post-quantum intent into an accountable programme.

    Security leaders · public institutions · boards 8 min read

    Reviewed

    Read note
  2. Entry 2

    Public-sector briefing

    Data custody is decided before a device is mounted

    Removable-media security is not principally a port-control problem. It is an authority problem: who may move which data, through which host and device, in which direction, for how long, with what surviving evidence.

    Regulated operators · government · critical systems 8 min read

    Reviewed

    Read note
  3. Entry 3

    Assurance note

    Evidence before scale: evaluating emerging cybersecurity products

    A polished demonstration can show possibility. It cannot, by itself, establish security, operability or scale. A disciplined evaluation separates the claim, the proof, the environment and the work still required.

    Buyers · investors · programme owners 9 min read

    Reviewed

    Read note
  4. Entry 4

    Technical foundation

    Identity beyond classical public-key assumptions

    Many logins, tokens and audit records still depend on integer factorisation and discrete logarithms. The migration question is larger than replacing one handshake: identity trust has to survive across its full lifecycle.

    Identity architects · security engineering · technical policy 6 min read

    Reviewed

    Read note
  5. Entry 5

    Agent identity briefing

    AI agents need delegated identity—not inherited API keys

    An agent should receive a bounded mandate that can be traced to an accountable authority. Passing down a reusable secret obscures that relationship and makes narrowing, expiry and revocation harder to govern.

    Security leaders · AI platform owners · public institutions 7 min read

    Reviewed

    Read note
  6. Entry 6

    Continuity briefing

    Identity when the network is absent

    Disconnection does not remove the need for identity. It changes which facts can be refreshed, which authority can be trusted locally and how long a decision may remain acceptable before reconciliation.

    Mission owners · identity architects · resilience teams 7 min read

    Reviewed

    Read note
  7. Entry 7

    Risk decision briefing

    Offline authorisation and the revocation gap

    An offline permission is an authority snapshot. If the central authority later revokes it, the disconnected endpoint may not know until trusted reconnection or local expiry closes the residual window.

    Risk owners · public institutions · custody architects 7 min read

    Reviewed

    Read note
  8. Entry 8

    Assurance language note

    Tamper-evident is not immutable

    Tamper evidence helps a verifier detect defined changes, gaps or reordering. It does not make storage impossible to alter, preserve every record forever or remove the need for independent witnesses and operating controls.

    Boards · assurance teams · security architects 7 min read

    Reviewed

    Read note
  9. Entry 9

    Privacy and assurance note

    Evidence without surveillance

    Accountability does not require collecting everything. Strong evidence begins with a decision purpose, admits only the fields needed to reconstruct it and gives every retained field an owner and an end date.

    Privacy leaders · security operations · public institutions 7 min read

    Reviewed

    Read note
  10. Entry 10

    Authority design briefing

    Why operator visibility must not become key authority

    A console may need to explain state, show evidence and initiate a governed request. It should not gain secret-release authority merely because it offers the clearest view of the system.

    Security architects · operators · governance boards 7 min read

    Reviewed

    Read note