What Cosmos 2612 did, and what proximity alone cannot do
Cosmos 2612 was launched from Plesetsk in April as one of six Russian military satellites. Between 14 and 20 May, five of them shifted onto the orbital plane of ICEYE-X36. In late September and early October, Cosmos 2612 performed a series of manoeuvres that matched it to X36’s orbital parameters. This was not a chance fly-by. It was an operation spread over five months.
According to LeoLabs, it began closing in on 15 October and was within 2–3 km a day later. At times the distance dropped to roughly 500 metres, and Orbital Radar reports 26 metres (!) on 19 October. Between 18 and 19 October, Cosmos 2612 began to move away. ICEYE stated only that it was aware of the situation and tracking it closely.
Proximity gives an attacker direct options: optical inspection, signals collection, and potentially interference with ground-segment communication. Each of them is worth more the more the attacker already knows. Which frequencies carry which traffic. What telemetry sequences look like. How the satellite reacts to component anomalies.
There is also an indirect, deniable option. The satellite does not have to be destroyed. It is enough to detune it: trigger an anomaly in a low-priority subsystem that does not raise an alarm but forces an automated response. A heater that runs slightly too long accelerates the degradation of batteries and electronics. Corrective manoeuvres performed slightly too often burn propellant. From the outside, the satellite simply appears to be ageing. This is how Stuxnet worked: the centrifuges at Natanz did not explode. For months, it altered their rotor speeds while showing operators a recording of normal operation, and the centrifuges failed one after another without anyone knowing why. It reached Natanz not through the internet, but through companies working with the facility. The weapon was the victim’s own automation. The prerequisite was detailed knowledge of how its software works.
That knowledge is not gathered in orbit. It sits in firmware, design documentation, test data, and ground-segment software, spread across a supply chain that often involves dozens of companies. Nothing public suggests any of that was compromised in this case. But the mechanism is clear: a rendezvous in orbit is the final step of an information-gathering process, not the first.
The heater question: an audit conversation worth more than the checklist
A few months earlier, I took part in an ISO/IEC 27001:2022 project for a manufacturer of electronic and space systems. One control changed the character of the work: A.8.28, Secure Coding. The question „do you have a secure development policy?” gave way to „show us how you write and review code”. That means the auditor sits down and talks with the R&D team, not with the policy owner.
A satellite has many subsystems, and many of them look irrelevant from a security perspective: thermal control, power management, telemetry. Each one runs its own firmware, and several communicate with the ground segment.
During one session, someone asked:
„If someone got close to the satellite — say, within a few hundred metres — could they read or disrupt the low-power communication interfaces of the heating subsystem (in other words, the heater), and move from there to something that matters?”
That is not a paranoid question. It is the question of a critical-systems engineer who understands the attack surface of their own product. The least glamorous subsystem usually has the least-reviewed code — and the most implicit trust from the rest of the platform.
A checklist will not lead you to that question. A conversation with an engineer will.
ISO 27001 secure coding controls protect the supply chain, not the spacecraft
ISO 27001:2013 already addressed development security through a secure development policy (A.14.2.1) and secure engineering principles (A.14.2.5). The 2022 revision made secure coding a standalone control, A.8.28. It sits within the cluster A.8.25–A.8.33, which runs from the secure development life cycle, through security testing and outsourced development, to separation of environments and the protection of test information.
Of course, Annex A controls do not apply automatically to every organisation; their applicability follows from the risk assessment and the justification in the Statement of Applicability (SoA). But an organisation that writes firmware for a spacecraft heading into orbit and excludes A.8.28 will, I would wager, have a difficult conversation with its auditor. Rightly so.
For a space supplier, five controls map directly onto the reconnaissance path described above:
- A.8.4 Access to source code: who holds the code, including external parties, and how quickly that access can be revoked.
- A.8.28 Secure coding: how firmware and ground software are written, reviewed, and tested against known weakness classes.
- A.8.30 Outsourced development: what subcontractors are contractually required to do, and who checks it.
- A.8.31 Separation of environments: whether development and test environments are separated from production, and whether development and test teams, including external ones, are kept from uncontrolled access to production systems.
- A.8.33 Test information: whether production data used in testing (including at subcontractors) is protected to the same standard as in production and deleted afterwards.
Even a sovereign system is a supply chain. In Poland’s POLSARIS programme, ICEYE delivered the space segment, and the state-owned WZŁ-1 (Military Communication Works No. 1) delivered the ground segment and mobile infrastructure. At least two organisations, two codebases, two groups of people with privileged knowledge.
So ISO/IEC 27001:2022 does not protect the satellite. It protects the people and systems that design, program, and operate it — because that is where an adversary does most of its homework.
What an ISO 27001 secure coding audit should actually ask
An audit that treats A.8.28 as a product control rather than a documentation control asks different questions. These are the ones I would put to R&D teams first:
- Which subsystems do you consider not security-relevant, and why? That list is the starting point for the threat model, not a reason to exclude anything from it.
- Show me the latest code review of firmware for a low-priority subsystem. Who did it, and against what criteria?
- Where does the source code live, who outside the company has access to it, and when did anyone last review those permissions?
- What does the subcontractor agreement require on secure coding? What evidence of compliance has the subcontractor actually delivered?
- Are test data and flight configurations in the integration environment protected to the same standard as in production?
These questions take longer than confirming that a policy exists. They need engineers at the table. But only they produce findings that matter to the product, not just to keeping the certificate.
What this means for space and defence suppliers
Open your Statement of Applicability and check what stands behind A.8.28. If it is a policy and a training attendance list, the control gives you compliance on paper; it does not actually protect the product.
If it is code review records, threat modelling that names your least glamorous subsystem, and verified security requirements implemented on the subcontractors’ side — good work, you are protecting what you actually build.
Cosmos 2612 left after a few days. The knowledge it arrived with did not fall from the sky. The best audits and advisory engagements I have taken part in were the ones where someone asked the proverbial heater question. If nobody asks it in yours, you are looking in the wrong place. Or you are missing someone who will ask it.
Sources: LeoLabs (via Via Satellite), Orbital Radar, and analysis by Marco Langbroek; distance estimates vary between sources. Control numbering follows ISO/IEC 27001:2022.