up:: Quantum Risk Models MOC

The Receipt Method

The receipt method is the way to measure your organization’s real migration speed, the Y term in Mosca’s inequality, from the documented record of a cryptographic migration you’ve already finished rather than from an estimate anyone produces on request. Find your last completed cryptographic migration, the SHA-1 exit, the TLS 1.0 kill, or a root CA rotation. Measure its duration from the day the decision was made to the day the last system stopped using the old algorithm. Carry that duration forward as your defensible Y, because it’s your own history rather than a vendor’s forecast.

The method applies to any organization that has completed at least one such retirement before, and it carries one hard guard: keep a separate Y per surface, because PKI, TLS endpoints, and embedded devices migrate on their own clocks, and the slowest sets your deadline.

The short version:

• Y, the migration-time variable in X + Y > Z, is the number organizations misjudge worst, and the receipt method replaces the guess with your own documented history.
• Find the last cryptographic migration you completed (a SHA-1 exit, a TLS 1.0 kill, a root CA rotation) and pull its records.
• Measure from the day the decision was made to the day the last system stopped using the old algorithm. The gap between decision and engineering start is budget cycles, procurement, and vendor waits, and all of it repeats next time.
• Keep per-surface receipts rather than a blended company-wide Y. The slowest surface sets the deadline, and averaging is how it disappears from the plan.
• The result survives a board’s scrutiny and an auditor’s, because a measured record beats a forecast every time the two disagree.

A lender sizing a mortgage reads your bank statements instead of asking how much you plan to save each month, because the statements are what you actually did and the plan is what you’d like to believe. The receipt method underwrites your migration timeline the same way. Your organization has already shown, in writing, how fast it moves when it decides to retire an algorithm, and that paper trail is the only migration forecast about you that has ever been tested against reality.

What is the receipt method?

The receipt method is a measurement procedure for Mosca’s Y that treats migration speed as a matter of record. Mosca’s theorem says you’re already late when X + Y > Z, where X is how long your data must stay secret, Y is how long your migration takes, and Z is how long until the cryptography can be broken. X has its own measurement discipline, the shelf-life question, and Z arrives from outside your walls. Y is the variable your organization fully controls and, in practice, the one it reports least honestly, because Y usually enters the plan as an engineering estimate produced under pressure to sound achievable.

The procedure:

1. Find the last completed cryptographic migration. Every mature organization has at least one: the exit from SHA-1 certificates and signatures, the removal of TLS 1.0 and 1.1, a root or issuing CA rotation, the retirement of an old cipher suite. Completed is the operative word. A migration that’s “mostly done” has no receipt yet.
2. Measure from decision day to last-system day. The clock starts the day the organization committed to the migration, in a steering-committee minute, a risk-register entry, or a budget approval. The clock stops the day the final production system stopped using the old algorithm, including the vendor appliance everyone forgot and the internal app that got 3 waivers.
3. Record the duration as your Y, per surface. The elapsed time between those two dates is your measured migration speed. It goes into the Mosca calculation as a dated, sourced figure, and it’s kept separately for each migration surface rather than blended into one company-wide number.

The method applies whenever a real completed migration exists in the record. Where none exists, the method breaks honestly, and the section on where it breaks covers what to do instead.

Why measure from the decision day instead of the engineering start?

Because the gap between the two is real time that your data spends exposed, and every component of that gap repeats in the next migration. When people pull a migration record at all, they usually start the clock when engineering started work, which quietly deletes a year or more of elapsed time. The deleted year is made of budget cycles that only open annually, procurement processes with their own calendars, vendor contracts that had to be renegotiated, and approval chains that ran at the speed of committees. None of that was engineering, and all of it was migration.

The distinction matters because Mosca’s inequality runs on calendar time, and so does the adversary. Data that must stay secret for 20 years gains nothing from the fact that your delay was administrative rather than technical. From the moment the organization knew it needed to move, every month before the last system moved was a month inside the exposure window, whichever department the month belonged to.

The public record shows the same gap at industry scale. The PCI Security Standards Council decided in April 2015, in PCI DSS v3.1, that SSL and early TLS had to leave payment systems by 30 June 2016. By that December the Council had measured the ecosystem’s actual pace and moved the deadline to 30 June 2018, roughly doubling the original runway before most of the engineering had even started. The plan was 14 months. The record says the industry needed more than 3 years.

Source: PCI Security Standards Council, “Date Change for Migrating from SSL and Early TLS” (18 December 2015), blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls; PCI SSC, “Migrating from SSL and Early TLS” resource guide (deadline codified in PCI DSS v3.2, Appendix A2, April 2016), listings.pcisecuritystandards.org/pdfs/PCI_SSC_Migrating_from_SSL_and_Early_TLS_Resource_Guide.pdf.

What counts as the last system?

The last system is the final production system that stopped using the old algorithm, and the definition is deliberately unforgiving. It includes the vendor appliance that validated firmware signatures with the old hash for 2 extra years, the internal application that renewed its waiver 3 times, and the partner integration that couldn’t move until the partner did. The receipt ends when the old algorithm’s production footprint reaches zero, because that’s the day the exposure the migration was meant to close actually closed.

The unforgiving definition is load-bearing for the Mosca calculation. Y protects the most exposed asset on the surface being measured, and the most exposed asset is, almost by construction, on the system that moves last. A migration that’s 95% complete still leaves the old algorithm alive on the systems that were hardest to move, which are frequently the systems carrying the longest-lived data, the pattern that harvest-now-decrypt-later exposure feeds on. Declaring the migration done at “substantially complete” measures the victory lap instead of the race.

Defining last-system day also has a practical benefit: it forces the receipt to include the long tail, and the long tail is where migrations actually spend their years. The web’s own SHA-1 exit shows the shape. The CA/Browser Forum passed Ballot 118 on 16 October 2014, banning new SHA-1 certificate issuance from 1 January 2016, and Chrome 56 stopped accepting SHA-1 certificates in late January 2017, so the most centrally controlled surface in security took about 2.3 years from decision to done. Meanwhile SHA-1 elsewhere, in firmware, internal PKI, and legacy signatures, runs on NIST’s phase-out clock all the way to 31 December 2030. Same algorithm, same evidence, and the last-system dates sit more than a decade apart depending on the surface.

Source: CA/Browser Forum, “Ballot 118 – SHA-1 Sunset (passed)” (16 October 2014), cabforum.org/2014/10/16/ballot-118-sha-1-sunset-passed; Chromium Security, “SHA-1 Certificates in Chrome” (Chrome 56, late January 2017), chromium.org/Home/chromium-security/education/tls/sha-1; NIST, “NIST Transitioning Away from SHA-1 for All Applications” (15 December 2022, phase-out by 31 December 2030), csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps.

Where do you find the receipt?

The records exist, because the moments that define the receipt each generated paperwork in a system that keeps timestamps. The decision day lives in governance artifacts: steering-committee minutes, the risk register entry that first named the migration, the budget submission that first carried its line item, the board or audit-committee deck that presented it. The engineering milestones live in change-management tickets, CA issuance logs, and project trackers. The last-system day is the one people rarely wrote down as an event, and it’s recoverable from instruments that recorded it anyway:

1. Vulnerability-scanner archives. The scan history shows the month the last host stopped presenting the old protocol or certificate, and the archive was written by a machine with no stake in the story.
2. Certificate Transparency logs. For anything in the public PKI, CT logs are an external, append-only record of when your last certificate under the old algorithm was issued and when its lifetime ended.
3. Change tickets for the stragglers. The final waiver closures and the decommissioning tickets for the holdout systems date the true end, and the waiver file itself is a preview of the next migration’s long tail.
4. Vendor correspondence. For appliance and firmware surfaces, the ticket thread where the vendor finally shipped the supporting release dates the moment your Y stopped being about you.

An afternoon in those 4 places usually produces a defensible receipt. The same afternoon usually produces the first honest conversation about the next migration, because the people who pull the records recognize every delay in them as a standing feature of the organization rather than a one-time accident.

What does a worked receipt look like?

Here’s the method run end-to-end on a generic enterprise SHA-1 exit. The dates are illustrative, chosen to show the shape the real records almost always reveal; the method’s whole point is that you’ll replace them with your own.

Receipt line item	Date on record	Where it was found
Decision. Steering committee approves the SHA-1 exit after the browser deprecation notices	March 2015	Steering-committee minutes, risk register
Budget lands in the next annual planning cycle	January 2016	First appearance of the budget line
Engineering start. New issuance chain live, re-issuance begins	May 2016	Change tickets, CA issuance logs
Public-facing TLS certificates fully re-issued	September 2016	CT logs, scanner history
Internal PKI and code signing converted, app by app	July 2018	Change tickets, waiver closures
Last system. A vendor appliance validating firmware signatures gets its supporting release and is upgraded	November 2019	Vendor ticket thread, final scan

Now read the receipt the way the method requires:

1. The measured Y is 4.7 years, March 2015 to November 2019, decision day to last system.
2. The remembered Y is about 18 months, because institutional memory keeps the span from decision to the visible milestone, the public certificates finishing in September 2016, and forgets the tail.
3. The decision-to-engineering gap is 14 months, one budget cycle plus procurement, and none of it appears in any engineering retrospective. It will reappear, at roughly the same length, in the next migration.
4. The last 3 years belonged to surfaces nobody presented in a status deck: internal trust stores, code signing, and a single vendor appliance whose upgrade waited on someone else’s release schedule.

The organization in this example would enter Mosca’s inequality with Y = 4.7 years for its slowest surface. If it instead carried the remembered 18 months, every deadline it derived would be wrong by about 3 years, in the direction that converts “we should start soon” into “we were already late.”

Why is one company-wide Y wrong?

Because a single blended Y is an average over surfaces that share nothing except a line in the same spreadsheet, and averaging is how the slowest surface vanishes from the plan. The estate migrates as several distinct populations. Public TLS endpoints sit behind centralized issuance and automated renewal, so they move fast. Internal PKI moves at the speed of trust-store updates and application regression testing. Embedded devices, appliances, and OT equipment move at the speed of vendor firmware releases and hardware refresh cycles, which can be geological. Splitting the worked example above into per-surface receipts makes the spread visible:

Surface	Decision to done	What set the pace
Public TLS certificates	1.5 years	Central issuance, automated renewal
Internal PKI and code signing	3.3 years	Trust-store updates, app-by-app testing
Embedded and vendor appliances	4.7 years	Vendor releases, hardware refresh cycles

The blended average of those 3 receipts is about 3.2 years, a number that reads plausible in a deck and describes none of the surfaces. Planning on it would declare the appliance fleet safe 18 months before its own history says it can finish, and the appliance fleet is exactly where long-lived signing trust tends to live. The rule is per-surface Y, slowest wins: the deadline for any given class of data is set by the slowest surface that data touches, and the blended number exists only to make the deadline feel farther away.

The guard has a second edge worth naming. Per-surface receipts also reveal where speed is purchasable. The 1.5-year surface earned its pace through automation and central control, which is crypto-agility doing its job, and the spread between the fastest and slowest surface is a measured, defensible statement of where agility investment would shorten the next Y.

What does the public record show about the decision-to-done gap?

Every major public migration with documented dates shows the same shape the worked example shows privately: the decision is fast to state and slow to finish, and the finish date routinely moves. The table collects the migrations whose decision and completion are both on the public record; Lessons from Past Crypto Migrations walks the fuller history.

Migration	The decision on record	The finish on record	Elapsed
SSL and early TLS out of payment systems (PCI DSS)	April 2015, PCI DSS v3.1 sets a 30 June 2016 deadline	Deadline moved on 18 December 2015 to 30 June 2018 after the Council measured the field’s real pace	~3.2 years, and the original 14-month plan roughly doubled
SHA-1 out of the public web PKI	16 October 2014, CA/Browser Forum Ballot 118, issuance banned from 1 January 2016	Chrome 56 stops accepting SHA-1 certificates, late January 2017	~2.3 years, on the most centrally controlled surface in security
TLS 1.0 and 1.1 out of the major browsers	15 October 2018, coordinated vendor announcements target March 2020	Firefox shipped the removal 10 March 2020, then reverted it so users could reach government sites that still hadn’t upgraded; the IETF formalized the deprecation in RFC 8996, March 2021	~2.5 years, with a slip past the target even under near-total vendor control
SHA-1 out of all US federal applications	2011, NIST SP 800-131A deprecates SHA-1 for new signatures	31 December 2030, NIST’s phase-out date for all applications	~19 years
DES retired as a US standard	November 2001, AES published as FIPS 197	19 May 2005, FIPS 46-3 formally withdrawn	~3.5 years for the standard, longer for Triple-DES in the field

Two readings matter for the receipt method. The elapsed column is a floor-setting reference: when the 4 browser vendors, with total control of their own products and 17 months of public notice, still slipped past their own date because the ecosystem around them wasn’t ready, a claim that your enterprise will cross a whole estate in 2 years needs a receipt behind it. And the PCI row is the receipt method operating at industry scale: the Council replaced a forecast deadline with a measured one within 9 months of publishing it, because the record overtook the estimate as soon as the record existed.

Source: PCI Security Standards Council, “Date Change for Migrating from SSL and Early TLS” (18 December 2015), blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls; CA/Browser Forum, “Ballot 118 – SHA-1 Sunset (passed)” (16 October 2014), cabforum.org/2014/10/16/ballot-118-sha-1-sunset-passed; Chromium Security, “SHA-1 Certificates in Chrome,” chromium.org/Home/chromium-security/education/tls/sha-1; Mozilla Security Blog, “Removing Old Versions of TLS” (15 October 2018), blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls; Mozilla, Firefox 74.0 release notes (10 March 2020, TLS 1.0/1.1 disabled, then “we reverted the change” for COVID-19 government sites), mozilla.org/en-US/firefox/74.0/releasenotes; IETF, “Deprecating TLS 1.0 and TLS 1.1,” RFC 8996 / BCP 195 (March 2021), rfc-editor.org/info/rfc8996; NIST, “NIST Transitioning Away from SHA-1 for All Applications” (15 December 2022), csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps; NIST, FIPS 197 (26 November 2001), csrc.nist.gov/pubs/fips/197/final; NIST, “Withdrawal of FIPS 46-3” (19 May 2005), csrc.nist.gov/news/2005/withdrawal-of-fips-46-3-fips-74-and-fips-81.

How does the receipt feed Mosca’s inequality?

The receipt is the Y-side measurement layer of the Mosca pair. Mosca’s theorem defines the inequality and teaches why X + Y > Z converts an uncertain quantum timeline into a present-tense decision. The Mosca inequality, worked runs the arithmetic across asset classes and Z bands. The receipt method is where the Y that enters those calculations comes from, the same way the shelf-life question is where X comes from: shelf life measures how long the data must stay secret by asking the business owner when publication stops hurting, and the receipt measures how long re-protecting it takes by pulling the organization’s own completed history.

Plugging a receipt into the inequality changes the character of the result. A Mosca calculation built on an estimated Y inherits the estimate’s optimism, and its conclusion can be argued down by anyone who prefers a smaller number. A calculation built on a measured Y is arithmetic on the organization’s own record: this data stays sensitive until a dated year (X, from the shelf-life question), the estate’s slowest relevant surface historically takes a measured span to migrate (Y, from the receipt), and the published planning horizons for Z are what they are. When that sum goes negative, the debate about whether the timeline is alarmist has nowhere to stand, because every input is either the organization’s own paper or a public document.

Common misconceptions

1. “Measuring Y from the engineering start is close enough.” The decision-to-engineering gap is commonly a year or more of budget cycles, procurement, and vendor negotiation, and every component of it recurs. Dropping it converts a 5-year receipt into a 3-year plan, and the missing 2 years get discovered at the worst possible time.
2. “One company-wide Y is fine for planning.” PKI, TLS endpoints, and embedded devices migrate on separate clocks, and the slowest clock owns the deadline. A blended Y reads like an answer while it hides the surfaces that move slowest and matter most.
3. “Our receipt is stale, we’re faster now.” Tooling improves; budget calendars, procurement rules, approval chains, and vendor dependency mostly persist. Unless the organization can point to a completed migration that proves the new speed, the old receipt remains the best evidence available, and claimed improvements belong in the plan as risks rather than as the baseline.
4. “A vendor’s migration forecast can stand in for a receipt.” A vendor forecast prices the slice of the estate their product touches, under assumptions that favor their roadmap. Your Y is estate-wide and includes every surface they’ve never seen. Forecasts are inputs to the plan; the receipt is the baseline the plan is judged against.
5. “Our last migration went badly, so it shouldn’t count.” The migration that went badly is the most honest receipt you own, because the same organization, with the same budget calendar and the same vendors, runs the next one. Discarding the bad receipt in favor of a clean estimate repeats the exact error the method exists to close.
6. “The receipt IS our post-quantum Y.” The receipt is the floor. The post-quantum transition replaces public-key algorithms with families that change key sizes, message sizes, and certificate structures, which is structurally more invasive than a hash swap or a protocol version bump, so history argues your PQC Y lands at or above the receipt. Treat the receipt as the best case with evidence behind it.

Pro tips

1. Date the decision from governance paper, never from engineering memory. The steering-committee minute, the risk register’s first entry, and the budget line’s first appearance are timestamped and survive staff turnover. Engineering memory reliably starts the story at the kickoff meeting.
2. Use instruments as witnesses for the last-system date. Vulnerability-scanner archives and Certificate Transparency logs recorded the tail whether or not anyone was watching, and a date recovered from an instrument is much harder to argue with than a date recovered from a recollection.
3. Pull the waiver file with the receipt. The systems that received exceptions in the last migration are, with high probability, the systems that set the last-system date in the next one. The waiver list is a preview of your next long tail, with names attached.
4. Interrogate instant answers. When someone offers “about 2 years” without opening a document, ask which completed migration produced that number. A measured Y has a receipt behind it; an estimated Y has a feeling behind it, and the follow-up question exposes which one you’re holding within a minute.
5. File the receipt where the next migration will find it. Enter the measured Y, per surface, with its source documents, into the risk register as a dated figure. The next migration then starts from evidence on day 1 instead of re-running the archaeology.
6. Read the per-surface spread as an investment map. The distance between your fastest and slowest surface is a measured statement of what crypto-agility is worth in your estate, in years, which is the strongest funding argument agility work ever gets.

Where does the receipt method break?

The method depends on a completed migration existing in the record, so it breaks honestly in a few situations, and each break has a disclosed workaround:

1. A first-ever migration has no receipt. An organization that has never completed a cryptographic migration has no record to measure. The substitute is the slowest comparable enterprise-wide change program on record, an operating-system end-of-life migration, a datacenter exit, an ERP replacement, measured the same way, decision day to last system, and presented with the substitution stated plainly: this is a proxy from the nearest comparable program, and cryptographic migrations, which reach into certificates, firmware, and vendor appliances, tend to run longer than the proxy suggests.
2. The estate transformed since the receipt was written. Heavy M&A, a major cloud migration, or a divestiture can make the old receipt describe an estate you’ve since replaced. The per-surface discipline is the repair: re-derive receipts for the surfaces that changed, keep the old ones where the estate still matches, and disclose the split.
3. Fully managed, vendor-run estates. Where nearly everything cryptographic is operated by providers, the organization’s own history measures mostly its dependency on other people’s clocks. The receipt still works, and what it measures shifts: pull the record of how long providers took to deliver past security transitions, because that lag is the dominant term in Y.
4. Reading the receipt as a ceiling. The method’s output is a floor for the post-quantum Y, for the structural reasons in the misconceptions above. Anyone using the receipt to argue the next migration can go no slower than the last one is holding the tool upside down.

How do you use the receipt in the boardroom?

The receipt turns the migration-timeline conversation from a negotiation over opinions into a review of evidence, and that shift is most valuable one level up, where the numbers get challenged. When a deck asserts “migration complete by 2029,” the receipt question is the sharpest one available to a director or an executive sponsor: which completed migration is that speed based on? A plan whose Y traces to the organization’s own record answers in a sentence. A plan whose Y was reverse-engineered from the desired end date has no answer, and the silence is itself the finding.

Presenting the receipt works best as 3 dated, sourced numbers side by side: X from the shelf-life question, Y from the receipt, per surface with the slowest one named, and Z from the published planning horizons. Boards extend more trust to historical figures than to forecasts, for the same reason auditors do, and a Y that cites the organization’s own steering-committee minutes and scanner archives moves the post-quantum line item out of the “believe me” category and into arithmetic. The receipt also protects the security leader who presents it: a timeline built on the measured record stays defensible in the postmortem if the program runs long, in a way no adopted vendor forecast ever is.

Questions people ask

What if we have no record of a past cryptographic migration? Use the slowest comparable enterprise-wide change program, an OS end-of-life, a datacenter exit, an ERP replacement, measured decision-day-to-last-system, and state openly that it’s a proxy. Cryptographic migrations tend to run longer than general change programs because the dependencies reach into firmware and vendor appliances, so treat the proxy as optimistic.

Which past migration makes the best receipt? The most estate-wide one you finished. A SHA-1 exit is usually ideal because it touched public certificates, internal PKI, and code signing at once, which yields per-surface receipts from a single program. A TLS version kill or a root CA rotation works well for transport and trust surfaces respectively.

Why measure to the very last system instead of substantial completion? Because Y exists to protect the most exposed asset, and the most exposed asset is usually on the system that moves last. The old algorithm keeps protecting production data until its footprint hits zero, so the exposure window closes at the last system, whatever the status report said.

Does the receipt include discovery and inventory time? Yes, automatically. Starting the clock at the decision captures everything that followed it, including the months spent finding where the old algorithm lived. That discovery phase recurs, larger, in a post-quantum migration, which is one reason the receipt is a floor.

Our environment is mostly cloud and SaaS now. Is the receipt still meaningful? Yes, with its meaning shifted. A managed estate’s Y is dominated by provider timelines, so the receipt to pull is the record of how long your providers took to deliver past transitions to your tenancy, plus the time your own integrations took to adopt them. Your history of waiting is still your history.

How often should the receipt be refreshed? Every time a migration completes, the new receipt supersedes the old one for the surfaces it covered. Between completions, revisit the per-surface receipts when the estate changes shape, after an acquisition, a major cloud move, or a divestiture.

Can we shorten Y once we’ve measured it? Yes, and the receipt is what makes the shortening measurable. The per-surface spread shows where central control and automation bought speed, which is the crypto-agility case stated in your own numbers, and the next completed migration shows whether the investment worked.

Is the receipt method part of Mosca’s theorem? It’s the measurement layer for one of its variables. Mosca’s theorem defines Y and proves why it matters; the receipt method is how Y gets a defensible value; the shelf-life question does the same for X; and the worked inequality shows the 3 variables deciding real cases together.

---

Everything here is the map, given freely. When your team needs its own receipts pulled, the per-surface Y measured against the record, and the result turned into a migration sequence a board will fund, that’s a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.