up:: The Human & Organizational Side MOC
Cryptographic Ownership
Cryptographic ownership is the assignment of clear, accountable responsibility for an organization’s cryptography: its inventory, its risk, its policy, and its migration. In most organizations no single person or function actually holds that accountability, and that vacuum is the most common reason a post-quantum migration stalls before it starts. Cryptography works quietly in the background for years, so nobody is put in charge of it, and a migration cannot be led by a role that doesn’t exist.
The short version:
- Cryptography usually has no owner, because it “just worked” for years and sits between teams that each assume another one holds it.
- A migration with no accountable owner doesn’t move. Naming one is the true first step, before discovery, before budget, before any code.
- No one function can own it alone: engineering does the work, procurement holds the vendor leverage, the CISO owns the risk, governance owns the deadline, and the board owns the money.
- Good ownership is one accountable executive owner, a cross-functional working group with an explicit responsibility map, and board-level sponsorship.
- Assign it first, and everything downstream, inventory, prioritization, vendor pressure, and rollout, has somewhere to live.
Think of cryptography as the plumbing of a large building. It runs behind every wall, everyone depends on it, and nobody thinks about it until something floods. When the pipes finally have to be replaced, the project stalls not on the plumbing but on the fact that no single person was ever responsible for all of it, so the first real task is deciding whose job it is.
Why does cryptography end up with no owner?
The vacuum is structural, and it recurs across almost every organization for the same reasons:
- It worked invisibly for decades. Classical cryptography rarely failed on its own, so there was never a forcing event that made someone take charge of the whole estate. Ownership tends to get assigned to things that visibly break.
- It’s genuinely cross-cutting. Cryptography lives in applications, infrastructure, networks, vendor products, hardware, and identity systems at once. No single existing team’s boundary contains it, so it falls into the seams between them.
- It’s nobody’s KPI. Engineers are measured on shipping features, procurement on cost and contracts, security on incidents. “The organization’s cryptography is coherent and current” is not on anyone’s scorecard, so it gets no dedicated attention.
- The expertise is thin and scattered. The few people who deeply understand the cryptography are usually individual contributors buried in engineering, not executives with the authority to run a cross-functional program.
The result is a diffusion of responsibility: everyone touches cryptography, so everyone assumes someone else is accountable for it, and no one is. The quantum transition is the first event in a generation forcing organizations to confront that gap, because now the invisible plumbing has a deadline.
Who are the candidate owners, and what does each control?
The migration spans functions that don’t normally share a mandate, and understanding why each one can’t own it alone is what tells you how to structure the ownership.
| Function | What it controls | Why it can’t own the whole thing alone |
|---|---|---|
| Engineering / platform | The implementation and the rollout across systems | Doesn’t control vendor contracts, the budget, or other teams’ priorities, so it can’t compel the coordination the program needs |
| Security / the CISO | The risk, the accountability, the regulatory mandate | Owns the outcome but usually not the engineers who do the work or the purchasing levers that move vendors |
| Procurement / vendor management | The contracts, the renewal timing, the leverage over vendors | Doesn’t assess cryptographic risk or run the technical migration |
| Governance / compliance | The regulatory obligation and the audit posture | Sets the deadline and the defensibility bar, but doesn’t do the work |
| Enterprise architecture | The standards and the target-state design | Advises and designs, but rarely holds delivery accountability or budget |
| The board / executive committee | The budget and the organizational priority | Funds and prioritizes it, but only once someone frames the ask and carries it |
Read down that table and the answer becomes obvious: because the levers are split across functions, ownership has to be an accountable executive plus a coordinating structure, not a single team handed an impossible mandate.
What does good cryptographic ownership look like?
A working ownership model has four parts, and the first one is the load-bearing one:
- One accountable executive owner. A single named executive, most often the CISO or a direct delegate, who is answerable for the migration’s outcome and has the standing to convene the others. Accountability that’s shared across a committee is accountability that belongs to no one.
- A cross-functional crypto working group. A standing group with real representation from engineering, security, procurement, architecture, and compliance, chartered to make decisions rather than just share status. This is where the split levers get coordinated.
- An explicit responsibility map. A written map of who is responsible, accountable, consulted, and informed for each part of the work: discovery, algorithm decisions, rollout, vendor engagement, and governance. Ambiguity here is where programs quietly stall, so it’s worth making painfully explicit.
- Board-level sponsorship. A named executive sponsor above the owner who has committed budget and priority, so the program survives competing demands and reorganizations.
The test of whether ownership is real is simple: if you ask five people “who owns the post-quantum migration,” a healthy organization gives you one name, and an unhealthy one gives you five shrugs or five different answers.
How do you actually assign it?
Assigning ownership is a sequence, and it comes before the technical work:
- Name the accountable executive owner first. Before discovery, before purchasing, before a line of code. Put the name in writing and make the outcome part of that person’s actual objectives, not a volunteer duty on top of a day job.
- Charter the working group. Give it a mandate to make decisions, a cadence, and representation from every function that holds a lever. A group that can only escalate, not decide, will move at the speed of the slowest calendar.
- Write the responsibility map. Assign responsible/accountable/consulted/informed for discovery, decisions, rollout, vendor engagement, and governance. Resolve the overlaps deliberately, because the overlaps are exactly where the work falls through.
- Wire in budget and escalation. The owner needs either budget authority or a fast, named escalation path to the sponsor. Ownership without the ability to spend or to unblock is a title, not a role.
- Make it visible. Report the program on the same cadence as any other executive initiative. Cryptography that stays invisible drifts back to being nobody’s job.
How does ownership connect to the rest of the migration?
Ownership is the keystone the whole program rests on, and its ordering is not optional. Without an owner, there’s no one to commission the cryptographic inventory, so there’s no visibility. Without visibility, there’s no defensible way to prioritize or to set a strategy. Without a coordinating structure, the split levers, engineering, procurement, governance, never come together, and vendor surfaces in particular go unpushed because chasing a vendor’s roadmap is nobody’s specific job. This is why migrations stall: the technical roadmap is the easy part, and it’s built on an organizational foundation that was never laid.
Common misconceptions
- “The security team owns cryptography.” They own the risk, and usually not the engineers, the budget, or the vendor contracts. Accountability without the levers is how a migration stalls with a CISO’s name nominally on it.
- “We have a crypto team, so we’re covered.” A crypto team is usually a handful of implementers, not an accountable owner with cross-functional authority. Implementation capacity and ownership are different things.
- “IT owns it.” Cryptography is cross-functional, spanning procurement, governance, and the business, not an IT-department task. An IT-only mandate is precisely how it lands in the ownership gap.
- “Everyone owns it, so it’s fine.” Diffuse ownership is the same as no ownership. If it’s everyone’s responsibility, it’s no one’s accountability.
- “We’ll assign an owner once we understand the scope.” Backwards. You can’t scope it without an owner to commission the inventory. Ownership comes first, and the scope follows from it.
Field note → The Psychology of Post-Quantum Risk, why the owner’s seat stays empty and why teams look away from their own exposure.
Everything here is the map, given freely. When your team needs the ownership structure designed and the migration run against your actual estate, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.