The key inside the machine that moves

THE OPERATOR'S MAP · Chapter: Twin & Machine · GFF 2026 Special · 11 September 2026. The five chapters advance together — agent controls (Ship AI), the open-source stack (Sovereign Stack), governance (The AI Boardroom), evaluation (Beyond the Benchmark), physical AI (Twin & Machine). This edition sits outside the episode numbering; its sibling chapters and this chapter's live predecessor are linked at the foot of the piece.

The lock is inside the machine, and the machine is in the field.

The Operator's Map is a series for the people who have to run AI rather than admire it: five chapters, one per domain, advancing together. This chapter teaches physical AI, the machines that act in the world and the controls that survive contact with them. This edition sits outside the episode numbering. Global Fintech Fest 2026 runs in Mumbai from 8 to 11 September (the organizer's site gives the dates and venues) on three pillars, which the government's own backgrounder names as "Potential to Impact: Agentic AI | Tokenisation | Quantum: Trusted, Connected, Global Systems for Inclusive Finance" and describes, for the third, this way: "Quantum technologies introduce a foundational shift in computation and security. From quantum-safe cryptography to advanced risk optimization, they strengthen systemic resilience and ensure long-term trust in the financial infrastructure of tomorrow." This chapter takes that third pillar, quantum, at the altitude where it is least discussed: not the laboratory, not the message rail between two central banks, but the sealed box on a counter, a wall, a pole or a factory floor that holds a key and will hold it for longer than the algorithm behind that key is allowed to exist. The other four chapters take the agent's slot, the ledger's sovereignty, the director's record and the week's numbers. This one asks which keys live inside machines that will still be in the field after the algorithm is deprecated. Every technical passage is restated in everyday words as it goes.

Why this reaches your desk. Two Indian regulators put the quantum pillar into the record this week in their own words, and both wrote it as a clock rather than a threat. The Reserve Bank's Deputy Governor said on 9 September that "we should not wait for a future vulnerability to become a present crisis before responding." SEBI's Chairman said on 10 September that "migration to quantum-safe systems cannot begin after the threat becomes real. It requires prioritisation of critical systems, crypto-agility and a phased transition to post-quantum cryptography." The Governor, the same day, named "the recently constituted Quantum Secure and Adaptive Financial Ecosystem (Q-SAFE) Committee on quantum resilience," whose terms of reference ask it to "Evaluate the financial sector's cryptographic inventory through a Cryptography Bill of Materials (CBOM), assess crypto agility and identify the critical systems and processes most vulnerable to such threats." Read those sentences as an operator and one word is missing from all of them: the machine. A cryptographic inventory of a bank is mostly servers, certificates and software libraries, which can be re-keyed from a desk. The part nobody can re-key from a desk is the fleet: terminals, ATMs, meters, controllers, each holding a key put there by a factory or a technician, each scheduled by its own standards body or its own contract to outlive the algorithm it uses. That is the row the committee's inventory will find hardest to fill. I have built against fielded devices for long enough to know that the interesting column in such an inventory is not the algorithm. It is the path by which the algorithm gets changed, and who has to drive.

Terms that matter this edition

1 · The terminal: the lock is inside the machine, and the machine is in the field

1.1 Start with the card reader on the counter, because it is the machine closest to the customer and furthest from the data center. When a chip card is presented, the reader checks a signature. EMVCo's own announcement of 28 October 2021 puts it plainly: "In an EMV contact chip payment, the merchant point-of-sale terminal can cryptographically authenticate a card and its data. For this purpose, EMVCo has based its EMV Contact Chip Specifications on RSA (Rivest-Shamir-Adleman) public key cryptography since its inception and intends to continue to support this standard." The word to read twice is terminal. The check happens in the box on the counter, against material that is in the box on the counter, and the industry already keeps a register of that material: the PCI Security Standards Council's PTS Program Guide says an approval listing prints, for every approved terminal model, "Key Management", "PIN Support (online, offline)", "Version" and "Expiry Date". A public record of which key-handling scheme sits inside which box, with a date on it.

1.2 Now the sentence this whole manual rests on. NIST's transition plan for post-quantum cryptography, IR 8547, is an initial public draft dated 12 November 2024, still a draft on 11 September 2026, and I will keep saying so because its dates are the ones everybody quotes. Section 2.2.3 of the draft's text reads: "Hardware modules must be upgraded or redesigned to support PQC algorithms, which often have larger key sizes and different computational requirements. This includes updating firmware or hardware to handle new algorithms and ensuring that the modules can perform quantum-resistant cryptographic operations efficiently while maintaining the high security standards expected of these devices." The body that wrote the algorithms says the hardware changes. A device whose lock is in silicon cannot take the new lock as a download.

1.3 The body that approves the terminals says what the change costs, in plain language. On 11 September 2025 the Council extended the expiry of the version 5 terminal class "from 30 April 2026 to 30 April 2027," and gave its reasons: "the extension is intended to support secure deployment continuity in the face of widespread ecosystem challenges, such as limited technician availability, constrained hardware supply, and complex upgrade timelines, particularly in embedded, unattended, and multi-component environments." Read that as a property of the class rather than as a news item. A terminal fleet is replaced at the pace of technicians and hardware supply, and the pace is slowest where the terminal is built into something else, has no attendant, and shares its enclosure with other parts: the vending machine, the fuel dispenser, the ticket gate, the parking barrier.

1.4 I want to concede the counter-case at once rather than let it sit. Some fleets re-key over the wire; remote key injection exists, signed firmware pushes exist, and in section 3 I will show an Indian public contract that requires exactly that for a different class of device. The concession sharpens the move. Two device classes can hold the same algorithm on the same expiry date and differ entirely in what it costs to change it, and the only column that records the difference is the path: remote inject, signed firmware, field visit, replace the unit. A manifest that records the algorithm and not the path is a list of what you own, not of what you can fix.

1.5 So the first rule of this manual, stated as a property of the class and not as a prediction about any machine: a key-bearing device that cannot be re-keyed remotely keeps its old lock until a technician arrives. Nothing follows from that about any particular terminal on any particular counter. What follows is arithmetic about a fleet, and the arithmetic is the next section.

1.6 The committee that will have to write this down for the whole Indian financial sector was constituted on 25 May 2026. RBI's press release gives its full name, an expert committee for a Quantum Secure and Adaptive Financial Ecosystem, a convener from IIT Madras, members drawn from the science and IT ministries, State Bank of India, NPCI and the Data Security Council of India, and six terms of reference, of which the second is the one that matters here: "Evaluate the financial sector's cryptographic inventory through a Cryptography Bill of Materials (CBOM), assess crypto agility and identify the critical systems and processes most vulnerable to such threats." The clock: "The Committee will submit its report within six months from the date of its first meeting." The release does not give the date of the first meeting, so I will not print a calendar date for the report. As of 11 September 2026 the only two RBI records of the committee are its constitution of 25 May and the Governor's naming of it on 10 September; RBI's press-release index for September and its notifications index, both re-read at 11:30 IST that day, carried nothing further.

1.7 Where the central-bank community has run post-quantum cryptography in an operational system is instructive for what it is not. The BIS Innovation Hub's Project Leap page, last updated 11 December 2025, says of phase 2: "By replacing traditional digital signatures with post-quantum cryptography while sending liquidity transfers, Leap Phase 2 demonstrated the feasibility of quantum-proofing payment systems." That is the message layer, the part of the estate that can be re-keyed by people who never leave their desks. The same page names "cryptographic inventory as critical foundations." As it read on 11 September 2026 it describes no experiment at the terminal, the meter or the controller, and I found none elsewhere in this run. The inventory the committee will build starts where Leap stopped.

2 · The ATM: device lifetime is the deadline, not the standard's date

2.1 Eight years ago the Reserve Bank ordered a fleet change and wrote the truck roll into the circular. On 21 June 2018 it wrote to every scheduled commercial bank other than the regional rural banks, every small finance bank, payment bank and white-label ATM operator about ATMs "running on Windows XP and/or other unsupported operating systems," and required them to "Upgrade all the ATMs with supported versions of operating system," phased so that "Not less than 25% of them shall be upgraded by September 2018," half by December 2018, three-quarters by March 2019, and "All of them shall be upgraded by June 2019." Then the sentence I would put on the wall of every fleet operator's office: "As the implementation of the foregoing control measures would also require field visit(s) to the ATMs, banks should plan and implement these measures in an optimal manner." No bank is named; a class is. The circular is about an operating system, not a key, and what it establishes is the pattern with a regulator's signature on it: a fielded class ran software past the date its vendor supported it, and the fix required a person at each machine, a quarter of the fleet at a time, over twelve months, under threat of enforcement. For the operating system nobody had published the support-end date years in advance. For the algorithm, somebody has.

2.2 The dates, with their status. NIST's landing page for IR 8547 reads, as printed: "NIST IR 8547 (Initial Public Draft)", "Date Published: November 12, 2024", and its document history has a single row, the draft. The address for a final version returned a 404 on 11 September 2026. Inside the draft's text, tables 3 and 4 put RSA and ECDSA signatures and the RSA and Diffie-Hellman key-establishment schemes at 112 bits of security strength as "Deprecated after 2030" and "Disallowed after 2035," and the stronger parameter sets, with EdDSA, as "Disallowed after 2035." The status words are defined in the same document: "Deprecated means that the algorithm and key length/strength may be used, but there is some security risk. The data owner must examine this risk potential and decide whether to continue to use a deprecated algorithm or key length." And: "Disallowed means that the algorithm, key length/strength, parameter set, or scheme is no longer allowed for the stated purpose." Every time 2030 or 2035 appears in this manual, read the word draft beside it. The draft itself allows that "others may adopt PQC at a slower pace due to legacy constraints or lower risk profiles." Legacy constraints is the polite name for the fleet.

2.3 The replacements are final, and still moving. FIPS 203, FIPS 204 and FIPS 205 each carry "Date Published: August 13, 2024." FIPS 204's page carries a planning note dated 31 July 2026 pointing to "several minor issues that will be corrected in a future update/revision of this publication"; FIPS 205's carries none. And NIST's project page, updated 5 August 2026, says "the Falcon digital signature algorithm and HQC key encapsulation mechanism were selected for ongoing standardization; that process is underway." A device designed today to the three final standards is designed to a set still being corrected and not yet closed, and a device with a fifteen-year life may need a second swap inside it. Record the algorithm on the manifest, never the phrase "PQC: yes."

2.4 Now put the machine lives beside the dates, class by class, from each class's own record. The terminal first. On 17 June 2025 the PCI Council extended the version 6 class: "The PTS POI v6 approval expiry date will also be extended 12 months from the current device approval expiry of April 2031 to April 2032." The rule behind the date is in the Program Guide: "Approvals for PCI-evaluated devices expire six years past the effective date of a subsequent update of the PCI security requirements." Two more rules from the guide matter for the manifest. "Effective with POI v6, firmware expires on 31 December every third year subsequent to the year initially approved." And a device that embeds another approved device inherits the worst date: "the expiration date shall be the earliest among all evaluations, including the embedded device itself." So a terminal approved this year carries an approval that runs past the draft's 2030 deprecation line. What happens to the box after that is, in the guide's words, a matter of "payment brand usage mandates for expired devices," and the guide keeps processing changes on expired devices because vendors "must still provide support for" devices already sold. The approval clock is not the device's life; it is the earliest date anyone has published for the class, and the life is longer.

2.5 The controller class. NIST SP 800-82 Revision 3, the operational-technology security guide of September 2023, sets the IT and OT lifetimes side by side in its text: "Typical IT components have a lifetime on the order of three to five years due to the quick evolution of technology. For OT, where technology has been developed in many cases for specific uses and implementations, the lifetime of the deployed technology is often in the order of 10 to 15 years and sometimes longer." A controller commissioned in 2026 with a fifteen-year life is in the field until 2041, six years past the draft disallow line, and the guide's qualifier, "sometimes longer," is an admission that the band has no hard right edge.

2.6 The meter class, with its provenance stated every time because it is the thinnest number in this chapter. In 2006 a US state utility regulator, deciding whether one utility could deploy a smart-metering system, adopted a useful life for it: "We find PG&E persuasive that the useful life of the system is 20 years," and "We will direct PG&E to depreciate the AMI equipment over 20 years." The same decision adds: "But technological obsolescence alone is not sufficient to warrant replacing the system." A metering fleet is replaced on an economic cycle set in a rate case, not on a software release. That is one regulator, one system, in 2006, the only regulator-stated meter life I fetched in this run; it goes on the figure as an annotation with its provenance printed, never as a band. From a 2026 install it runs to 2046. The Indian record supplies structure rather than a number. The Ministry of Power's model contract for smart prepaid metering, version 4 of August 2022, runs for up to "10 (ten) years from the date of execution of the Contract" or 93 meter-months from go-live, whichever comes first; at the end of it the provider transfers the hardware to the utility, and "the meters shall have a warranty of five years from their installation." The meter is written to outlive the contract that installed it. I derive no meter life from the ten-year term; the document states none.

2.7 The arithmetic, which is the whole of this move: migration window equals lifetime minus today. Against the draft's dates, write lifetime end minus 2035 and read the sign. Negative is margin: the machine leaves service before the disallow date. Positive is the years the machine will be in the field after the algorithm inside it is disallowed. For the version 6 terminal approval class the number is minus three, and it is the approval that lapses, not the box. For the top of the controller band it is plus six. For the one meter life on record it is plus eleven. Those are class numbers, not predictions about any site; they move if the draft moves, and they do not move if your regulator has not set a date, because the machine's life does not depend on the regulator.

2.8 How long did the last swap take? EMVCo's FAQ on its elliptic-curve announcement says: "In 2010, the U.S. National Institute of Standards and Technology (NIST) announced that it would not support the use of EMV's longest RSA 1984-bit key length after 2030," and "It has taken EMVCo time" to fold the replacement into the specification. The announcement adding ECC is dated 28 October 2021. From notice to specification: eleven years. And the algorithm it added is itself on the draft's "Disallowed after 2035" row. The last algorithm change in payments took longer than the time now left before 2035, and it landed on an algorithm with a published retirement date.

2.9 The objection to this section is jurisdictional and it is fair: IR 8547 is a draft addressed to US federal systems, and a terminal in Mumbai or Riyadh is not bound by it. True, and no Indian instrument in this run sets a date; RBI's committee is asked to "Recommend a roadmap and framework to quantum-secure the Indian financial system," and SEBI's Chairman names "a phased transition" without one. The answer is that the devices are global even where the rules are not. Every CISA advisory this week prints "Countries/Areas Deployed: Worldwide"; PCI approvals are one global list with one set of dates. The vendor's roadmap follows the earliest binding date anywhere, and the device in your field meets that roadmap whether or not your regulator has set a clock. The US cyber agency's own page states the premise without a date: "Although quantum computing technology capable of breaking modern public-key encryption does not yet exist, government agencies and critical infrastructure entities—including both public and private sector organizations—must begin preparing now." The arithmetic is yours regardless.

3 · The meter: a bill of materials is an inventory of paths

3.1 RBI's terms of reference name a format, so start with what the format holds. CycloneDX, the OWASP standard that publishes it, describes a CBOM as enabling "detailed representation of cryptographic assets within a system. This includes algorithms, keys, certificates, and their relationships to software components." I read the version 1.6 schema by script on 11 September 2026, and the fields are good ones for the question in this chapter. A component can be of type device, firmware or cryptographic-asset. An algorithm records its primitive, its parameterSetIdentifier, its executionEnvironment, whose allowed values include software-plain-ram, software-tee and hardware, its certificationLevel, and a nistQuantumSecurityLevel where "A value of 0 indicates that none of the categories are met." Key material records a state "as defined by NIST SP 800-57," an expirationDate, and a securedBy mechanism with the examples "HSM", "TPM", "SGX", "Software", "None". Every row of that is what an operator needs to know about the lock.

3.2 Now what the schema does not hold, from the same read: no field for where the device is, none for who holds the maintenance path into it, and none for whether the key can be replaced without a visit. That is not a defect in the format; CycloneDX is a software bill of materials that grew a cryptography section, and software does not have a location. But for a fleet those three absences are the columns that decide the cost of the migration. The worked artifact in section 6 adds them, and one more, labeled as this chapter's additions.

3.3 The meter class is where the difference between a lock and a path shows up in a public document. The Ministry of Power's model contract for the national smart prepaid metering rollout requires of the service provider: "Remote firmware update: It shall be possible to update the firmware of the meters in both Unicast (one to one) and in Multicast fashion (Group of meters)." And: "Security patch management of all applications shall be encrypted and signed." So the meter class in India re-keys over the wire by contract, in groups, with signed patches. The terminal class has no such instrument in this run; its standards body's bulletin in section 1 describes the constraint in technicians and hardware supply instead. Two classes, the same public-key algorithms, the same draft retirement dates, and a completely different answer to the only question that costs money. A bill of materials that records only the algorithm cannot tell them apart. One that records the path can, which is why I call the CBOM an inventory of paths rather than an inventory of algorithms.

3.4 The same contract already demands the row this chapter is asking for, and it did so before the format existed. Clause 2.7.7, item n: "For smooth functioning of the entire system, it is essential that the AMISP shall provide in the form of a document enough details of such algorithm including the mechanism of security key generation to the Utility. In case of proprietary or secret mechanism, the same shall be kept in a secured escrow account." The go-live deliverables table lists, as item five, "Document detailing security algorithm and security key generation method." And the exit plan requires the provider to "Handover the list of all IT Assets, passwords at all locations to Utility." That is a CBOM row demanded by contract for a fielded device class in India, in a public-sector model document dated August 2022, nearly four years before RBI's terms of reference named the format. The question for any utility that signed it is whether anyone collected the document, whether it has been updated since go-live, and whether it says which meters can be re-keyed in a multicast group and which cannot. Column 21 of the worked artifact is where that answer goes.

3.5 A correction I owe the record. The word inventory belongs to RBI, to CISA, to the BIS, and, under the name "the mechanism of security key generation," to the Ministry of Power. It does not belong to SEBI's Chairman. His published address contains no occurrence of the word; what it says is "prioritisation of critical systems, crypto-agility and a phased transition to post-quantum cryptography," and that "SEBI's Cybersecurity and Cyber Resilience Framework recognises quantum computing as a potential cybersecurity threat." SEBI's own press release on the keynote summarizes the passage under cyber and quantum resilience and names no inventory. Secondary reports put "cryptographic inventories" in his mouth; the two documents the regulator published on 10 September do not.

3.6 Why the list cannot be made by a scanner. The joint CISA, NSA and NIST factsheet of 17 August 2023 says it in one note: "Discovery tools may not be able to identify embedded cryptography used internally within products, hindering discoverability or documentation. Organizations should ask vendors for lists of embedded cryptography within their products." It also says the inventory should be led by procurement and "should include engagements with supply chain vendors." The inventory of a fleet is therefore a procurement artifact, produced by asking, not a scan output, produced by running. The factsheet adds the row most inventories miss: quantum-vulnerable systems "include those involved in creating and validating digital signatures, which also incorporates software and firmware updates." The key that signs the update that would re-key the device is itself on the list. In the vocabulary of this series, and of the chapter that follows this one in this lane, the maintenance path is the control path, and the key is what the path is for. The honest objection is that a CBOM will in practice be produced by scanners over code, and every fielded device will appear as "vendor firmware, unknown." I agree that this is what will happen if the CBOM is treated as a scan output, and I say it is the finding rather than the failure: the unknown rows are the inventory of paths nobody has tried, and an inventory is a claim until someone tries each path, which is where this lane's third chapter ended. The tested control counts.

4 · The controller: the path, station by station

4.1 The controller class sets the cost of the path in the standard's own words. SP 800-82's comparison of IT and OT lists the location difference, "Components can be isolated, remote, and require extensive physical effort to gain access to them," the scheduling difference, "OT outages must often be planned and scheduled days or weeks in advance," and the support difference, "OT may use OSs that are no longer supported." Put those beside the terminal bulletin's "limited technician availability" and the ATM circular's "field visit(s)" and three bodies that were not describing the same thing have described the same stations.

4.2 A record from this week shows the last station, the one people forget. On 10 September 2026 CISA republished a vendor security bulletin as advisory ICSA-26-253-01, for a pipeline-monitoring software product, AVEVA Pipeline Integrity Monitor. Two of its four defects are cryptographic, and the vendor reported both to CISA itself; the advisory's acknowledgments say so. The first is CWE-321, "Use of Hard-coded Cryptographic Key," where "The vulnerability, if exploited, could allow a miscreant with read access to PIMBoards project files to decrypt and view sensitive information." The second is CWE-327, "Use of a Broken or Risky Cryptographic Algorithm," which the vendor's own bulletin, AVEVA-2026-006 dated 8 September 2026, names as "Passwords Hashed with MD5." CISA scores the first at CVSS 3.1 8.4, high, with an attack vector of local, AV:L. The remedy is a re-key, and the vendor says what kind: "Important: PIMBoards Project Files migration from older versions to AVEVA Pipeline Integrity Monitor 2025 SP1 P2 is one-way due to the changes in password hashing algorithms and end-user managed encryption keys." For files that cannot be migrated, "implement stricter read access controls to protect these unsafe files."

4.3 Three things about that record, stated so nobody reads more into it than it holds. It is software, not a box on a wall; its attack vector is local; and neither CISA nor the vendor claims any physical consequence, so none is claimed here. The product is named because the vendor published the record about its own product and reported the two defects to the agency; both records are cited beside the name, and nothing here characterizes the company. Of the three industrial-control advisories CISA's listing shows for 8 to 11 September 2026, this is the only one whose defect class is a cryptographic key or algorithm (a second carries a hard-coded credential, CWE-798, a different class) and the only one the vendor disclosed itself; the other two are described by class only. What the record teaches is a property of re-keying that has nothing to do with this product: a migration of key material can be one-way, and the order of operations is decided before the first device, not after. That is station seven of the path, the station a project plan written from a desk leaves out.

4.4 Count who performs each station on that figure. The vendor holds one, four and seven. The technician, who may be yours or a service partner's, holds six. The standards body sets two and three. You hold five, and you hold the question at one. Four of the seven stations are performed by someone who is not you. That is why the worked artifact carries a column for who holds the path, and why the answer "us" should be written only when you have tried it. The meter class is the exception at station four, where the contracted over-the-wire branch exists, and that branch is the entire cost difference between the classes.

5 · The terminal, offline: the edge case that proves the rule

5.1 The rule that defines a payment made with no network at all is RBI's Framework for Facilitating Small Value Digital Payments in Offline Mode, issued 3 January 2022 and updated in place, most recently on 4 December 2024. Its definition: "An offline payment means a transaction which does not require internet or telecom connectivity to take effect." Its mechanics, each a separate line in the annex: "Offline payments shall be made in proximity (face to face) mode only." "Offline payment transactions may be offered without Additional Factor of Authentication (AFA)." "The upper limit of an offline payment transaction shall be ₹500. The total limit for offline transactions on a payment instrument shall be ₹2,000 at any point in time. For UPI Lite 1, the enhanced limits shall be ₹1,000 per transaction with ₹5,000 being the total limit. Replenishment of used limit shall be allowed only in online mode with AFA." Its liability line: "The acquirer shall incur all liabilities arising out of technical or transaction security issues at merchant's end." And its own footnote on how far offline goes: "UPI Lite transaction is offline to the extent that AFA is not required, and transaction alerts not sent in real time." Read that as a description of a key rather than of a payment, and read which device holds the key. The caps sit on the payer's instrument, not on the merchant's terminal: offline payments "may be made using any channel or instrument like cards, wallets, mobile devices, etc." and the ₹2,000 is the total "on a payment instrument." Between the first tap and the replenishment, the instrument is paying out value the network has not seen, trusting nothing but the material inside it; the caps bound how much it may pay alone, the replenishment rule is the moment the network takes over, and the liability line says who carries the interval. The terminal is the other half of the pair. A terminal that authenticates a card without asking the host, the check section 1 quotes EMVCo placing inside the terminal, decides with the key material inside it and nothing else. For a few hundred rupees at a time, then, two keys act and neither consults the network: the instrument decides alone within its cap, and the terminal that accepts it decides with what is in the box.

5.2 A clarification the week needed. UPI Tap & Pay on point-of-sale terminals, launched at the festival on 10 September, is not this case. NPCI's own release of that date says: "The feature does not rely on user's mobile internet connectivity as transactions can be completed using the POS machine's internet connection." So the phone may be without data; the terminal is online; the transaction completes on the terminal's connection. The operating circular behind it, NPCI/UPI/OC-186A/2026-27 of 10 September 2026 (the circular, listed on NPCI's UPI circulars page), is an image-only scan, and I quote it as transcribed from the scanned circular: payee providers are to "enable UPI Tap & Pay only on NFC-enabled PoS terminals that are certified in accordance with the Payment Card Industry PIN Transaction Security / Contactless Payments on Commercial Off-The-Shelf (COTS) devices (PCI PTS / CPOC) standards"; and settlement is "in accordance with the extant UPI guidelines." It says nothing about connectivity. An earlier draft of this manual had Tap & Pay completing at a terminal with no network. The record says otherwise, and the record wins.

5.3 What this lane takes from the circular is not the ceiling; the ₹5,000 no-PIN threshold is a limit enforced by the rail rather than by any model, and the Ship AI chapter of this edition takes it as its own rung. What this lane takes is the device-class control: a Tap & Pay terminal must be certified to PCI PTS or CPOC, which places every one of them inside the approval-expiry clock of section 2, with an "Expiry Date" and a "Key Management" entry on a public listing. The rail tied a new payment mode to the terminal's own lifecycle record, and that is the instinct the rest of the fleet needs.

5.4 Now the point the edge case proves. In section 7 I quote the NIST draft's full sentence on authentication; the short form is that an authentication system stays secure as long as its algorithms are secure at the moment the authentication happens. An offline device does nothing but authenticate, which EMVCo in section 7 says of every terminal; what offline adds is that the device decides without the host, so the key inside it is the only control in the interval. Nothing it does can be recorded today and decrypted later; it only proves that this card, or this instrument, is real, right now, against this key. So it is the last device anyone will bother to re-key, because it is the least exposed, and the first whose old algorithm must be switched off on the day a capable quantum computer exists. Both are true at once, and only the manifest tells you how many such devices you have and which of them can take the switch-off remotely.

5.5 The objection here is that caps of ₹500 and ₹2,000 make the exposure trivial and the key beneath notice. The framework's own liability line is half the answer; the acquirer carries "all liabilities arising out of technical or transaction security issues at merchant's end," whatever the cap. The other half is the class point: the cap bounds each transaction, not the number of instruments and terminals holding the same key material with the same expiry and the same re-key path. The exposure is the fleet, and the fleet is the CBOM's unit.

6 · The manifest

6.1 The first worked artifact is the CBOM table for a fleet of machines that move, one row per key-bearing device class, twenty-one columns, every one traceable. Column 1 is the device class. Columns 2 to 12 are the CycloneDX 1.6 fields of section 3. Column 13 is the algorithm's transition status for 2030 and for 2035 from IR 8547's draft tables, with the word draft in the header. Columns 14 and 15 are the PCI approval expiry and the three-year firmware expiry, with the embedded-sub-component rule noted. Column 16 is the device's lifetime end, from the commission date plus the class lifetime. Column 17 is the years in the field after the draft's disallow date, lifetime end minus 2035, positive when the device outlives the date, with the formula printed so nobody has to trust the cell. Columns 18 to 21 are this chapter's additions and the header says so: location_class, rekey_path, path_holder and vendor_list_received, the last of which is the factsheet's "ask vendors for lists of embedded cryptography" and the Indian contract's "Document detailing security algorithm and security key generation method" turned into a cell.

6.2 Three instructions are printed on the artifact, and they are the difference between an inventory and a spreadsheet. Fill it for one device class, not the fleet; a row that says "terminals" is a policy, and a row that says "version 5 unattended terminals in fuel forecourts, approval expiring 30 April 2027, re-key by field visit, path held by a service partner, vendor list not received" is a finding. Every unknown is a row, not a blank. Column 21 is answered by the vendor, not by your records.

6.3 The second worked artifact is the maintenance-path checklist for a re-key, ten numbered items, one per station of the path in section 4 plus three this manual added, each closing with the source sentence it rests on. Two of the additions are the ones the path alone would miss: for any instrument or device that acts offline, write the cap the instrument acts under and the moment it reconciles; and do not skip the classes whose algorithm is "only" authentication, but write beside them the draft's own words, that "authentication using these algorithms will need to be disabled." The third dates the checklist and re-runs it when any source it rests on moves. When Q-SAFE reports, the operators able to answer it will be the ones whose columns 18 to 21 are already filled, because no scanner and no sector-wide survey can fill those on an operator's behalf. The report's date is not published. The manifest can be started today.

7 · The strongest counterargument

7.1 The best argument against this chapter is in the NIST draft itself, and I carry it in full. Section 3.1.2 of IR 8547 reads: "Unlike with encryption, where there is a threat of ‘harvest now, decrypt later,’ an authentication system remains secure as long as the cryptographic algorithms and keys used to perform the authentication are secure when the authentication is performed. Authentication systems may continue to use quantum-vulnerable algorithms until quantum computers that are capable of breaking current, quantum-vulnerable algorithms become available, at which point authentication using these algorithms will need to be disabled." The draft continues: "Supporting quantum-resistant algorithms for authentication will require upgrades to both the system performing and accepting the authentication, as well as to any supporting infrastructure, such as a PKI. It may also require obtaining hardware cryptographic tokens that support the quantum-resistant algorithms." EMVCo says the same of cards, in its FAQ: "It is important to note, however, that EMV Chip exclusively uses cryptography for real-time payment authorisation and terminal PIN protection. This contrasts with other use cases that need information that is protected now to remain confidential for many years and survive the arrival of cryptographically significant quantum computers." So a terminal that only authenticates is not a harvest-now-decrypt-later exposure. The 2035 line is written for data that must stay secret; the terminal keeps no such data. On this reading the fleet can wait, and the money should go to the message layer, where the BIS experiments already are.

7.2 I concede every word of it, and then read the sentence to its end: "at which point authentication using these algorithms will need to be disabled." On a fielded fleet, a disable order is the truck roll: the same seven stations as section 4, with two differences that make it worse. The date is not yours; it is the date a capable machine exists, which no standards body has set and no rate case has depreciated toward. And the order is disable, not migrate, so a device that cannot take the new algorithm does not degrade gracefully; it stops authenticating, which for a payment terminal means it stops. The draft's own next sentences say the upgrade requires "both the system performing and accepting the authentication," the PKI behind them, and possibly "hardware cryptographic tokens." The steelman moves the date. It does not remove the van, and it takes the choice of day away from you.

7.3 Four things would falsify the rest of this chapter, and I would rather name them than be found by them. A final IR 8547 with different dates or status words, which would change every draft-qualified sentence here and possibly the sign in column 17; the address for a final returned 404 on 11 September 2026 and is the first thing to re-check. A rail or regulator instrument that re-keys a terminal class over the wire at fleet scale, which would move that class's rekey_path from field-visit to remote-inject; I found no such instrument for terminals in this run. A CycloneDX schema release with fields for device location, path holder or remote re-key ability; version 1.6 has none. And a Q-SAFE report with a device-class finding, which would replace this manual's arithmetic with the committee's, and which I would welcome.

What to ask your team

1. For each device class we operate, terminals, ATMs, controllers, meters, gateways, which key is inside it, in which algorithm, and is it in software or in a chip? Show me the row, not the policy.
2. What is the commission date and the class lifetime of the oldest unit still in service, and does the lifetime end before or after 2035?
3. Which of our terminal models are approved under PTS POI version 5, and what is our plan for 30 April 2027?
4. Have we asked each device vendor, in writing, for the list of embedded cryptography in their product, and which vendors have not answered?
5. For each class, is the re-key a remote injection, a signed firmware push, a field visit, or a replacement unit, and who holds that path, us or a service partner?
6. Which of our instruments and devices act offline, under what cap, and when does each one reconcile?
7. If a vendor tells us a key migration is one-way, what is our order of operations, and who signs it?
8. For any device we procured under a contract that already requires a key-generation or embedded-cryptography document from the vendor, do we hold that document, and when was it last updated?

Cut in verification, and why

• A second industrial-control advisory from the same week, for satellite terminals. CISA's second advisory dated 10 September 2026, on the ICS advisories listing, concerns fielded terminals, but its defects are authentication and authorization classes, not cryptographic keys, and the acknowledgments credit an external researcher rather than the vendor. Under this series' naming rule the product could be described only by class, and the class point is carried by the self-disclosed record in section 4. Cut.
• The RBI Governor's 10 September passages on fraud tooling, the lending and market interfaces and tokenized bonds. In the fetched speech; they belong to the sibling chapters. This lane quotes only the Q-SAFE clause of paragraph 32.
• The SEBI Chairman's passages on the Demat 2.0 pilot. In the fetched address; the Sovereign Stack chapter's evidence.
• A line attributed to the SEBI Chairman in press reports that an AI-generated alert is not a finding. Zero occurrences in the published address and zero in SEBI's own press release on the keynote. Not this lane's claim.
• The PIB backgrounder's Agentic AI pillar sentence. Contains a phrase this series does not use; only the theme line and the Quantum pillar sentence are quoted.
• Any incident, loss, or injury involving a payment terminal, ATM, meter or controller. Excluded by this lane's standing discipline. Consequence in this chapter is stated only as a property of the machine class and never as an event. The one defect record cited is a software product with a local attack vector and no physical consequence claimed by the agency or the vendor, and none is added here.
• Political speeches at the festival. Not fetched. This edition cites regulators and operators only.

Did not resolve

• A final NIST IR 8547. The address for one returned 404 on 11 September 2026; the draft is cited as a draft throughout. This is the single most consequential open item in the chapter.
• NPCI's UPI Lite product page and FAQ. The site's public paths returned 403 to every automated route; the live product path was not attempted in the browser session. The two documents this chapter needed from NPCI, the 10 September release and circular OC-186A, were fetched inside a browser session on 11 September 2026 and are cited above. The UPI Lite pages were not read, so the offline mechanics in section 5 rest on RBI's framework, which is the instrument anyway.
• A FIPS 206 draft for the Falcon signature scheme. Its expected address returned 404; the project page's "underway" sentence is used instead.
• The live PCI PTS approval listing, device by device. Behind an acceptance gate the fetcher cannot pass. Column names are cited from the Program Guide and class dates from the Council's bulletins; no per-device row is cited.
• EMVCo's current annual RSA key-length bulletin. The located address returned 404. The 2021 FAQ carries the 2010-to-2030 sentence used in section 2.
• An Indian numeric meter life. The Central Electricity Authority's meter regulations were not fetched; the Ministry of Power's model contract states structure but no number, so the only regulator-stated meter life here is the 2006 US decision, labeled as such.
• Confirmation that version 4 of the model smart-meter contract is the current one. The nodal agency's landing pages returned a generic shell; the version 4 document and its guidance note were fetched directly, and the guidance note names no later version.
• A Q-SAFE report or interim release. None on RBI's press-release index for September or its notifications index, both re-read at 11:30 IST on 11 September 2026; the RBI reports and publications pages were not separately checked. The first-meeting date, from which the six-month clock runs, is not published.

Next in the series

Next in the series, for this lane: "Load a program. Start it. Over the network.", the chapter in which the maintenance path is the control path.

The series

This is the Twin & Machine chapter of The Operator's Map, GFF 2026 Special. The four sibling chapters of this edition each take one of the festival's pillars at their own altitude. Ship AI: "The agent gets a slot, not a button" takes agentic AI, and where a delegated payment's limit is enforced. The Sovereign Stack: "A token settles where the ledger is sovereign" takes tokenization, and which layer settles the token. The AI Boardroom: ""The model said so" is not an answer" takes all three as a director's ledger. Beyond the Benchmark: "Ninety-five percent is a projection" takes the numbers the week shipped. This lane's live predecessor is Episode 3, "A demonstration proves the vendor's day", where the tested control counts. Readers of this chapter's publication would find the sibling publications of the same edition the most useful next read.