Cybersecurity debates often begin with exploits, malware and exposed servers. Ukraine’s continuing dependence on 1C/BAS skills highlights another layer of security engineering: software provenance and institutional migration. A product can become unacceptable because of ownership and sanctions even without a public finding that every installed version contains a particular technical flaw.
Public job advertisements show why that distinction matters. Military Unit A5118 sought an accountant in March and listed 1C, 1C Accounting and BAS skills. Military Unit A4640 advertised for a head of accounting and reporting with experience in 1C and BAS. A Kyiv regional territorial recruitment and social support center also listed familiarity with 1C-type accounting software as useful for an accounting role.
These postings do not reveal a network diagram or prove active deployment in a classified environment. Hiring data is indirect evidence. It shows that organizations still value knowledge of the software ecosystem, which may reflect active use, archival access, compatibility requirements or a migration process. For security analysis, that is enough to identify a potential legacy dependency that merits direct inventory and verification.
A similar point applies to Diia. Its June 25 finance and economics vacancy expected high-level knowledge of 1C, BAS or comparable software. This is evidence about the financial back office, not the citizen-facing application. Diia’s technical teams separately recruit for mobile services, DevOps, APIs, systems analysis and red-team security. Conflating those layers would produce a technically misleading story.
Ukraine’s SSSCIP gives unusually clear guidance on the legal side. The agency explicitly discusses 1C and BAS in its prohibited-software FAQ and says their inclusion is tied to the sanctioned rights holder, 1C LLC. It also states that the list is a sanctions-policy instrument and should not be interpreted as a technical security or performance rating for each product.
This distinction mirrors a broader principle in supply-chain security. Technical risk asks whether a component can be exploited. Provenance risk asks whether the supplier, owner, update channel or legal relationship is acceptable. Organizations need controls for both. A product can fail a provenance policy even when no public zero-day is known, just as a trusted domestic product can still contain a technical vulnerability.
For covered Ukrainian systems, the provenance decision has binding operational consequences. Listed software is prohibited in systems processing state information resources, official data, state secrets and critical information infrastructure. SSSCIP says the rule applies even in air-gapped systems. That is logical from a governance perspective: an air gap may reduce remote attack paths, but it does not change ownership, maintenance history or legal status.
The agency also links prohibited components to security authorization. A system containing them can be ineligible for approval, and an existing authorization can be revoked if noncompliant components are discovered. Inspections can require remediation. In other words, the control is intended to be enforceable through the lifecycle of the information system, not only at procurement.
The scale is increasing. On July 17, SSSCIP expanded its prohibited software and communications-equipment list from 1,079 to 1,341 positions. At that size, manual awareness is inadequate. Effective implementation requires software asset inventories, bill-of-materials thinking, rights-holder data and a process for tracing where a newly prohibited component is deployed.
Migration creates a second security problem: change risk. ERP systems hold financial history, permissions, payroll and integrations. Moving them can cause data loss, access-control mistakes, broken reporting or operational disruption. A rushed migration from a prohibited system to a poorly configured replacement can simply exchange one risk for another. Security therefore needs to be embedded in the migration plan, not treated as the reason to skip testing.
Ukraine’s market response recognizes this complexity. On July 28, IT Ukraine and Germany’s GIZ announced an additional voucher program to help small businesses replace 1C/BAS with modern ERP systems. Financial support can accelerate migration, but technical quality will depend on data mapping, identity and access controls, backups, validation and secure integration design.
The original material also attributed 1C/BAS use to Fire Point. MAIR found no independent support for that specific claim in the public Fire Point vacancies reviewed. The company’s DOU profile confirms its defense-tech work, but its use of these accounting platforms remains unverified. This is a useful example of why cybersecurity reporting needs evidence boundaries as much as systems need trust boundaries.
Ukraine’s case is ultimately about mature cyber governance. Security is not only patching code. It is knowing what software exists, who controls it, where it runs, what data it touches and how to remove it safely when the risk or legal environment changes.
