up:: The Human & Organizational Side MOC
The Undocumented Estate
The undocumented estate is everything true about your cryptography that exists only in somebody’s head. How the certificate authority hierarchy is actually wired, as against how the diagram says it is wired. Which cipher suites break which legacy client. Which HSM firmware tolerates which key ceremony. Where the hardcoded moduli are buried and why a change to one of them took down billing in 2019. None of it is in the CBOM, all of it is load-bearing for a migration, and the people carrying it are the ones most likely to leave during the crossing.
The short version:
- The inventory captures what cryptography exists. The undocumented estate is how it actually behaves, and only the second one tells you what breaks when you change something.
- Losing the holders during a migration does more than slow it, because the dependency knowledge required to retire a path safely leaves with them.
- The crossing is precisely when they go, since a long period of ambiguity is clarifying to anyone with options and demoralizing to everyone else.
- It stayed undocumented because it was never a deliverable, and because writing it down is difficult to distinguish from training a replacement.
- The move that works is authorship rather than knowledge transfer. The person who holds it owns writing the new standard.
Think about a municipal water system where one engineer knows that the valve marked 14 on the drawing is actually valve 12, that the pressure on the north loop reads 8 psi high, and which two houses lose supply if you close the wrong main. The asset register is complete and accurate. The knowledge that keeps the town in water when someone digs is not in it, and it retires with him.
Why is this the most expensive risk on the human side?
Because it converts a schedule problem into a feasibility problem.
Most migration risks make the work slower, and this one can make part of it impossible. Retiring a classical path safely requires knowing every dependent, and for the oldest and highest-risk parts of the estate that knowledge is frequently held by 1 or 2 people and written down nowhere. When they leave, the organization is left with a system it can migrate only by discovering the dependents through outage, which no risk committee will approve. The result is an estate segment that quietly moves from pending to permanent, usually without anyone recording the moment it happened.
The compounding detail is that the holders are concentrated exactly where the risk is. Modern services with active teams and current documentation are the parts that move easily anyway. The payments path, the embedded fleet, the 15 year old integration, and the certificate hierarchy nobody has rationalized are where both the risk and the undocumented knowledge sit.
Why do these people leave during a migration specifically?
Because the crossing removes the thing their standing rested on, and it removes it in public.
During a long hybrid period the senior practitioner is briefly incompetent at the new material while their old expertise stops being decisive. Competence is unavailable in both directions. That state is uncomfortable for everyone and it is intolerable for the person whose professional identity was built on being the one who knew. It also lands as a status disclosure they will not make out loud, because saying out loud that the thing you were best at has stopped being the thing that matters is close to impossible in a design review.
So it presents as silence. The senior person going quiet in design reviews, deferring more, and raising fewer objections looks identical to agreement, and it is usually the opposite. By the time it becomes visible it is a resignation, and the notice period is not long enough to extract 15 years of estate knowledge from someone who is already gone in every sense that matters.
The people with options are the ones who act on this, which selects precisely the wrong departures.
Why has none of it been written down?
For three reasons, and only the third is about the individual:
| Reason | What it looks like | What changes it |
|---|---|---|
| It was never a deliverable | Documentation was scoped to what the system is, and the knowledge is about how it misbehaves | Commission the write-up as work with time allocated, rather than as something done between tasks |
| It is hard to write down usefully | The knowledge is conditional and situational, so it reads as trivia until the day it matters | Capture it as failure modes and dependencies rather than as description |
| Writing it down resembles being replaced | The request lands as “make yourself unnecessary”, especially during a migration that already threatens their expertise | Frame it as authorship of the new standard, with their name on it, per the reframe below |
The third one is the binding constraint, and it is the one most programs walk straight into by asking for a knowledge transfer session.
Why won’t your vendor tell you about this?
Because no product captures it and no tool can discover it.
Discovery tooling finds cryptography in systems, which is genuinely valuable and is a different thing entirely. A scanner can tell you a service negotiates a given cipher suite. It cannot tell you that the suite is pinned because a partner’s terminal fleet fails on anything newer, that the workaround was agreed verbally in 2018, and that the person who agreed it retires in March. That gap between the inventory and the operating reality is where migrations actually get stuck, and it is invisible to every dashboard in the category.
It is also uncomfortable for an advisor to raise, because the version of the finding is that a specific named person is a single point of failure, and that sounds like a criticism of the organization rather than a description of every large estate ever built.
What do you actually do about it?
- Find the holders before you need them. Ask, per system rather than per person, who would have to be consulted before this is changed. The names repeat quickly, and the list is usually 5 to 10 people for a large estate.
- Offer authorship instead of asking for a transfer. The person losing decisive expertise is the right person to own the new standard, write the migration patterns for their own domain, or run adversarial review of the design. It converts a demotion in competence into a promotion in scope, costs almost nothing, and it is the difference between being consulted and being replaced.
- Keep a knowledge-at-risk register alongside the inventory. For each estate segment: who holds the operating knowledge, whether any of it is written down usably, and what the migration cannot proceed without. It turns an uncomfortable conversation into an ordinary risk entry with a mitigation and an owner, which is also what makes it fundable.
- Capture failure modes rather than descriptions. The useful artifact answers “what breaks, under what conditions, and who is affected” for each system. That is the form the migration actually consumes, and it is a more natural thing to write than a system overview.
- Read the silence. Quiet from a senior practitioner during a crossing is information. Somebody should be having an ordinary, non-loaded conversation with each holder well before the migration reaches their domain.
- Use the open estate. While the inventory is being built and the code is already being modified is the cheapest moment this decade to write down what was never written down, and the marginal cost is far lower than commissioning it as its own project later.
Common misconceptions
- “Our documentation is good, so this does not apply.” Documentation describes intent. The undocumented estate is the accumulated difference between intent and behavior, and every estate older than a few years has one.
- “We will do knowledge transfer before they leave.” Notice periods are weeks and the knowledge is years deep. The transfer has to happen while the person is engaged and has standing, rather than while they are leaving.
- “This is a people problem, not a migration risk.” It determines whether specific systems can be retired at all, which makes it a feasibility input to the plan. Treating it as an HR concern is how it stays off the risk register.
- “Newer tooling will discover it.” Scanners find cryptography. They do not find the verbal agreement with a partner, the reason a version is pinned, or which client fails silently rather than loudly.
- “If someone is a single point of failure that is their fault.” It is the ordinary result of a system nobody was ever asked to document, maintained well for years by someone who was rewarded for keeping it running.
Questions people ask
How do we find the holders without making it feel like an audit? Ask about the systems rather than about the people. The question of who has to be consulted before a change is routine, and the names surface without anyone being profiled.
What if the holder has already left? Then the affected segment moves to a slower, more expensive path: rebuilding dependency knowledge through testing and staged rollback rather than through recall. Price it accordingly and record it, since this is the case that quietly converts a segment into permanent residual risk.
Is a knowledge-at-risk register really worth maintaining? It is the artifact that makes this fundable. Endings and people work has no natural milestone, so it loses every budget argument to something with a delivery date. A register with named segments and named risks competes on the same terms as any other risk entry.
Does authorship actually work as compensation? It works when it is real. An invented role is transparent to the holder and insults them more precisely than exclusion, because it signals that leadership knew a part was needed and could not find a genuine one. The migration genuinely needs standards written, patterns designed, and designs attacked, so the parts are available.
What about the specialist who does not want a broader role? Adversarial review of the migration is the part that fits. Somebody has to attack the hybrid design, the downgrade paths, and the parameter choices, and skepticism about the new primitives is the qualification for that job rather than an obstacle to it.
How does this interact with the inventory? The inventory tells you what exists and this tells you what it costs to change. Running them together is far cheaper than running them 2 years apart, because the same conversations produce both.
Can AI tooling help extract this now? Somewhat, and it is a genuine change from a decade ago, since drawing tacit knowledge out through structured interrogation and writing it up is much more tractable than it was. It shortens the write-up rather than removing the need for the holder to be willing, which is still the binding constraint.
Go deeper
- Operating Through a Long Hybrid Period: the crossing during which these people are most likely to leave.
- Change Management for Cryptographic Migration: the resistance this knowledge sits underneath, and how to read it.
- Cryptographic Bill of Materials (CBOM): the inventory this note is the missing half of.
- The Turned-Off Test: the measure that surfaces exactly where dependency knowledge is missing.
Everything here is the map, given freely. When your team needs the holders identified, the knowledge-at-risk register built, and authorship structured so the estate knowledge is captured before it walks, that’s the work I do.
Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.