For most fleets, CryptoPro Secure Disk is not in the asset register at all, because the pre-boot layer arrived inside a product a device maker built and integrated, which is how the software ended up in some ATMs by way of Diebold Nixdorf's Vynamic Security Suite [4].
Teams tend to assume the asset register covers operating systems and the applications that have vendor portals. In practice it covers the line items procurement signed. Disk encryption and pre-boot authentication that a manufacturer embedded is a dependency rather than a purchase, so it sits in nobody's patch queue by default.
The propagation path has three hops before a fix reaches a running machine. The developer releases a patch, the company that implements the product builds a tailored fix, and then the customer has to hear about it and install it, which is hard for equipment in the field that cannot easily be paused [11]. CryptWare's managing director, Uwe Saame, says the nine bugs went out in two phases, 7.7.2 in early November and 7.7.3 in early December [6]. CryptoPro does not appear to publish update notes publicly, and Burch believes the company told its own customers directly [8]. If you are not a customer of record, there is nothing to read.
Diebold Nixdorf's spokesperson says two of the nine are relevant to its Vynamic Security Hard Disk Encryption, that fixes went out in December, and that neither bug could have compromised one of its ATMs on its own [9]. Subtract and seven are, by that account, somebody else's problem to scope [14]. The Wired account carries scoping from exactly one integrator, and none from the other embedded-device makers or the large Windows shops also named as buyers [5][15]. It also dates the Black Hat and Defcon talks as "this month" while dating the patches to early November and December without years, so a reader cannot compute how long the fixed bugs sat before disclosure [16].
Burch's own argument is that the obscurity these niche products relied on is thinning, because AI tooling lets people assess unfamiliar software without deep domain expertise [13]. The practical response is to put the pre-boot layer on the same register you already keep for the OS. The tradeoff is that you will be tracking versions you cannot patch yourself, and your only lever is the integrator's change-management calendar, which is where Diebold says deployed ATM updates get coordinated per customer [12].
Two questions sort the work. Can you name the pre-boot and full-disk-encryption component and its version on a given fleet, and can you update it without touching the hardware.
- Named and remotely updatable: ordinary patch work. - Named, physical touch required: a scheduling and truck-roll problem, budgeted rather than debated. - Unnamed but remotely updatable: one call to the vendor of record fixes the gap permanently. - Unnamed and physical: you are trusting a notification you may never see, for a component you cannot look up.
The cheap version of this is a line in the next renewal asking the vendor to name the third-party crypto components in its product and say where their fixes get published. Researchers have spent decades arguing against security through obscurity, and finance and medical device makers have made some progress on transparency and patch adoption [17]. Progress in the vendor's disclosure practice is not the same as progress in your register.
