Bulgarian Government Faces Digital Sovereignty Risks in Microsoft Procurement

Bojidar Bozhanov has raised a red flag: the Bulgarian government is preparing to open a public procurement and sign a new, large-scale contracting arrangement with Microsoft to cover core software and cloud services for the state administration — a move he says carries long-term risks for national security and digital sovereignty.

Background​

Bojidar Bozhanov, a technologist-turned-politician who formerly served as Bulgaria’s Minister of Electronic Governance and today holds a senior role in the parliamentary opposition, publicly warned that a recent decision by the Council of Ministers instructs the Minister of Electronic Governance to launch a procurement procedure for Microsoft products for the state administration. His warning is rooted in three interlocking facts: the administration relies heavily on Microsoft server software (notably Windows Server and SQL Server), the state budget includes funds earmarked for Microsoft licensing, and the procurement language allows procurement of Microsoft products “or equivalent,” which in practice may enable extended reliance on Microsoft cloud and identity services.
This is not a theoretical debate. Government documents and budget planning show a centralised approach to licensing and subscription management for the public sector, and parliamentary records indicate that millions in the 2026 budget are set aside to cover license requirements. The Council of Ministers’ procedural decision to task the e‑Governance ministry with running a central procurement sets the legal and administrative wheels in motion.
Bozhov’s intervention reframes the procurement as a policy and sovereignty decision rather than only a technical or financial one. He notes three practical features of Microsoft’s modern enterprise stack that shape the risk calculus: (1) the push to consolidate identities into Azure AD/Entra, (2) the prevalence of cloud‑integrated collaboration through Microsoft 365 (Office apps plus cloud services), and (3) the historical inability of customers to fully control encryption keys in certain cloud configurations — a factor with legal and geopolitical consequences.

---

Overview: what is at stake​

The decision before Bulgarian authorities is deceptively simple: renew licensing and support for server products and office productivity platforms, or choose different tools. In practice, it raises deeper issues:

• Operational continuity — Many government back‑end systems are currently certified to run on Microsoft server ecosystems; replacing them is costly and slow.
• Fiscal efficiency — Centralised licensing can reduce duplicate purchases and increase bargaining power, but may also lock multiple agencies into long contracts.
• Digital sovereignty — Relying on an American cloud provider for identity, email, collaboration, and servers raises questions about control of encryption keys, extraterritorial access by foreign authorities, and the ability to migrate services quickly if geopolitical pressures mount.
• Security tradeoffs — Microsoft provides mature security tooling and a global partner support network, but centralising critical services with a single vendor concentrates failure points and potential attack surfaces.

These tradeoffs are now politicised: they are argued in the open by a former e‑Governance minister who has inside knowledge of procurement, by opposition parties worried about dependency, and by government ministers who emphasize operational practicality and cost.

---

The technical picture: what Microsoft would provide, and what it means​

Core products under consideration​

The procurement scope described in public documents and comments includes server and platform products such as:

• Windows Server (server OS for many back‑end systems)
• SQL Server (relational database systems used by public registries)
• Microsoft 365 / Office 365 (productivity apps plus cloud services for email, collaboration and file sharing)
• Azure Active Directory / Entra (cloud identity management)
• Azure and related platform services for hybrid or cloud hosting

These are enterprise‑grade offerings with deep integration between identity, device management, email, collaboration, and platform services. They represent a full‑stack approach to the “modern workplace” model many governments adopt.

Identity consolidation: Azure AD / Entra​

Microsoft’s cloud identity service (now part of the Entra brand) is the backbone of cloud‑delivered authentication and device management. Centralising identities into Azure AD enables streamlined SSO, conditional access policies, and easier administration — but it also means the state’s user directory and access control plane are managed through a vendor’s cloud service.
Technical options exist (for example, hybrid identity deployments or on‑premises Active Directory Federation Services), but the default Microsoft‑recommended posture often emphasizes cloud‑first identity and management. That increases dependence on a single vendor’s control plane and, unless mitigated, can complicate rapid migration away from the vendor.

Data control and encryption keys​

A central technical and legal concern is who controls encryption keys. Modern cloud providers — including Microsoft — offer customer‑managed keys (CMK) and hardware security module (HSM) integration, which allow organisations to hold and manage keys used to encrypt data at rest. These capabilities are important mitigations, and they are widely available in Azure’s portfolio.
At the same time, specifics matter. Not every workload or service supports customer‑managed keys in the same way; some managed services still rely on provider‑controlled platform keys unless explicitly configured otherwise. For a government, full control of key lifecycle and an operational model that prevents vendor or foreign legal access without oversight is the differentiator between perceived sovereignty and dependency.
Microsoft has expanded government‑grade capabilities (including differentiated clouds, BYOK/CMK options and confidential computing), but the difference between “available as an option” and “default, audited, and guaranteeable in procurement terms” remains crucial.

Microsoft’s government and sovereignty features​

Microsoft markets specific features designed for public sector use: Azure Government offerings, Customer Lockbox, customer‑managed keys, and confidential computing. These expand options for governments to limit provider access to data, require judicial process for disclosures, and operate hybrid models where critical keys or systems remain in state‑controlled infrastructure.
These features materially reduce some risks, but they require deliberate architectural choices, contract clauses, and operational oversight — they are not automatic outcomes of a standard procurement. The public sector purchaser must require and validate specific controls as part of the contract.

---

Geopolitical context and the “sanctions risk” example​

One of the most publicly discussed cases tied to the debate is the reported incident involving an international institution that moved away from Microsoft’s cloud services, citing concerns that arose after a period of high‑level geopolitical pressure that affected an official’s access to a Microsoft‑hosted mailbox. That migration to a European open‑source platform has been widely reported and used as an illustration that heavy dependency on US tech platforms can expose institutions to service or access risks when political tensions escalate.
The incident is complex and not a straightforward demonstration of vendor malfeasance: there are conflicting reports, vendor statements denying deliberate action, and legal questions about how cross‑border requests for data are processed. Still, the episode shows the optics and operational anxieties that drive policy makers toward seeking alternatives or insisting on stronger contractual and architectural protections.
This case crystallises two lessons for public procurement:

• Infrastructure decisions are exposed to geopolitical dynamics, not just technical failures.
• Contractual and architectural protections (e.g., key control, data residency, explicit service availability SLAs) are essential complements to vendor assurances.

---

Financial picture: budget, scale, and hidden costs​

Public budget documents discussed in parliamentary hearings indicate that multi‑million euro allocations are intended for licensing and support. Centralised purchasing can yield discounts via bulk procurement, predictable upgrades, and vendor support, but the sticker price is only part of total cost of ownership (TCO).
Hidden or deferred costs to consider:

• Migration costs for alternative platforms, including staff retraining, system re‑engineering, and application compatibility efforts.
• Interruption and integration costs if some agencies choose alternative stacks while others stay on Microsoft, creating interoperability complexity.
• Long‑term vendor lock‑in costs: switching large, integrated identity and collaboration platforms after multiple years of consolidation is expensive.
• Opportunity costs from limiting competition or overlooking local‑market vendors and open‑source options that might support domestic industry or smaller integration scopes.

A complete procurement should include a realistic TCO analysis covering a 5–10 year horizon and modelling migration scenarios and incident responses, not only the immediate licensing fees.

---

Procurement design: how "or equivalent" shapes outcomes​

Government procurement documents reportedly include phrasing such as “or equivalent.” That clause can be read two ways:

• As a genuine market test that allows open competition and consideration of non‑Microsoft offerings that meet functional requirements.
• Or, in practice, as a mechanism that preserves Microsoft‑centered procurement while leaving only cosmetic possibilities for alternatives.

The difference depends on how requests for tender are drafted and evaluated. Procurement frameworks that specify functional requirements, interoperability standards, and vendor‑agnostic acceptance criteria increase the chance of meaningful competition. Conversely, procurement that lists Microsoft products by name and then tacks on “or equivalent” without firm evaluation metrics effectively preserves the incumbent.
Three procurement safeguards are advisable:

• Define functional outcomes and interoperability requirements, not brand lock‑in.
• Require demonstrable support for customer‑managed keys, data residency guarantees, and audited access procedures.
• Publish migration and exit plans as mandatory contractual deliverables to reduce lock‑in risk.

---

Alternatives: technical and policy pathways​

Governments do not have only one path. Options include:

• Hybrid approach: maintain on‑premises or state‑controlled infrastructure for the most sensitive systems (with customer‑managed keys), while using Microsoft or other clouds for less sensitive workloads.
• Multi‑vendor strategy: avoid concentration by splitting critical services across providers, with federated identity bridges and standardised APIs.
• Phased open‑source adoption: for collaboration and productivity suites, evaluate European open‑source stacks (and bundled solutions) that can be hosted under local jurisdiction.
• Invest in migration and sovereign infrastructure programs: fund local data centres, domestic hosting, or shared EU‑based platforms to reduce long‑term dependency.

Each path brings tradeoffs. Open‑source alternatives can improve sovereignty and reduce vulnerability to extraterritorial legal mechanisms, but they often require additional maturity, integration work, and local support ecosystems. Hybrid and multi‑vendor strategies increase architectural complexity but reduce single‑point‑of‑failure risk.

---

Security implications: centralised vendor versus heterogenous stack​

Security is an ambiguous argument in this debate. On one hand, Microsoft offers robust security tooling, threat intelligence, and global incident response capabilities that many national administrations cannot replicate. Consolidating on Microsoft can raise the baseline security posture quickly.
On the other hand, centralisation increases the blast radius of any compromise or unilateral action. If identity, mail, and file services are aggregated under a single cloud account structure, then an outage, misconfiguration, or compelled data access can affect many functions simultaneously.
Mitigations include:

• Enforcing the strictest possible contractual limits on provider access, coupled with CMK and HSM usage.
• Auditable support workflows (e.g., Customer Lockbox) and staunch operational transparency obligations.
• Segmentation of critical services into separate legal and technical domains.
• Regular third‑party audits and public reporting of compliance with required controls.

Security decisions cannot be abstracted from governance: technical controls only protect if procurement and contract language mandate their use and if auditors verify them.

---

Policy and governance recommendations​

If the state proceeds with a Microsoft‑centred procurement, policy makers should ensure that the deal adheres to explicit sovereignty, transparency, and resilience requirements:

• Insist on customer‑managed encryption keys for all systems holding sensitive data, with contractual guarantees and operational proof.
• Require detailed exit and migration plans in all multi‑year contracts, including data export formats, service portability tests, and vendor cooperation clauses.
• Publish procurement scoring matrices and allow independent review to ensure "or equivalent" truly means open competition.
• Build a multi‑year digital sovereignty roadmap that includes investment in local capability, open‑source pilots, and multi‑vendor architectures.
• Require regular, public compliance audits and incident transparency reporting to the parliament and relevant oversight authorities.

A procurement that fails to embed these elements may deliver short‑term convenience at the price of diminished strategic autonomy.

---

Risks that must be explicitly acknowledged​

• Vendor lock‑in — once identity, collaboration, and back‑end services are consolidated, switching costs steepen and agility falls.
• Geopolitical exposure — extraterritorial legal instruments and political pressure can have operational effects even if providers deny collusion; architecture must assume this possibility.
• Hidden migration costs — replatforming legacy systems away from Microsoft server ecosystems can become a multi‑year, multi‑million effort.
• Concentration of failure — a single misconfiguration or outage impacting an integrated cloud tenancy can cascade across multiple agencies.
• Insufficient contractual guarantees — product features exist to mitigate many risks (CMK, confidential computing), but their protective value depends on contract, verification, and operations.

Where claims are not fully verifiable in public reports (for example, precise legal interactions between governments and vendors in specific incidents), procurement must adopt a precautionary approach: assume that disruption is possible and build contractual and technical resilience accordingly.

---

What a robust procurement looks like — checklist​

• Functional, measurable requirements (not brand names) for identity, mail, collaboration, and data encryption.
• Mandatory customer‑managed keys (BYOK) and HSM integration for sensitive data.
• Explicit SLAs for availability, plus runbook entries for incident response and continuity.
• An independently auditable access governance model (e.g., Customer Lockbox with mandatory approvals).
• A binding migration and exit plan, tested during the contract’s first year.
• A staged adoption plan that allows pilot projects with open‑source or EU‑based alternatives.
• Public disclosure of procurement scoring and vendor evaluation criteria.

---

Conclusion​

The Bulgarian Council of Ministers’ move to authorise a procurement for Microsoft products presents a classic governance tradeoff: the operational pragmatism of adopting mature, widely used commercial platforms against the longer‑term strategic imperative of digital sovereignty and resilience.
Microsoft’s product suite brings operational benefits, strong security tooling and ecosystem support — all attractions for cash‑strapped public administrations that need predictable updates and professional support. But those advantages do not obviate the need for careful procurement engineering. Without explicit contractual guarantees over key management, exit strategies, and auditability, centralising critical functions on a single foreign provider can create dependencies that are costly and slow to reverse.
The optimal path is rarely binary. A well‑structured procurement can buy the practical benefits of mature vendor technology while protecting sovereignty through hybrid architectures, customer‑managed keys, multi‑vendor strategies and transparent, enforceable contractual commitments. The alternative — a broad, open cheque to maintain or extend vendor dominance without verifiable protections — is the exact risk Bozhidar Bozhanov warns about.
Public officials and IT leaders must not treat procurement as mere license renewal. This decision is a strategic one, touching national security, digital autonomy, fiscal prudence and the ability of the state to function independently in an increasingly fraught geopolitical landscape. The technical options exist to mitigate many of these risks; the political and procurement will to require and verify those mitigations must follow.

---

Source: fakti.bg https://fakti.bg/en/bulgaria/102815...-za-darjavnata-administracia-koeto-e-riskovo]

 

[ChatGPT]

Bojidar Bojanov’s public warning that the Bulgarian Council of Ministers is about to authorise a central procurement for Microsoft products is more than a procurement squabble — it’s a live debate about digital sovereignty, vendor lock‑in, and the practical limits of cloud dependency for a modern state. His post lays out three interlocking facts: the administration’s heavy reliance on Microsoft server software (Windows Server, SQL Server), the procurement language that permits “Microsoft or equivalent” purchases, and the architectural shift that binds identity and collaboration to Microsoft’s cloud stack (Azure AD / Entra and Microsoft 365). These are operational realities with strategic consequences, and they deserve to be treated as policy choices rather than mere IT housekeeping. view
Bojanov, a former Minister of Electronic Governance and current opposition figure, framed the government move not as a routine license renewal but as a structural decision that will affect how Bulgarian public services operate for years. The Council of Ministers’ instruction to the Minister of Electronic Governance to run a central procurement can consolidate licensing and support for multiple key products — from server OS and databases to email, collaboration, and identity services. Consolidation brings efficiency but also multiplies risk when the pieces of the public administration’s digital infrastructure depend on one vendor’s cloud control plane.
This debate is playiecent events that crystallise the underlying geopolitical risk: the International Criminal Court (ICC) experienced a suspension of access to a prosecutor’s official email account after U.S. sanctions were imposed, an episode that prompted the ICC and other European actors to re‑examine dependence on U.S.-based cloud providers. The ICC’s subsequent procurement move toward Germany’s ZenDiS and the openDesk open‑source workspace is being reported as an attempt to reduce those dependencies. Multiple news outlets have covered the ICC episode and the shift toward openDesk, and ZenDiS itself presents openDesk as the German sovereignty alternative for public administration.

---

Why this procurement matters: the technical and strategic stakes​

The scope: it’s not just Office licences​

A central procurement for “Microsoft products” in a public administration rarely means word processors only. The procurement under discussion includes:

• Windows Server and related server components that host core registries and line‑of‑business applications.
• SQL Server and other Microsoft database platforms that underpin public registries and transactional services.
• Microsoft 365 / Office 365 (cloud‑enabled Word, Excel, Outlook, SharePoint, Teams) for email, collaboration, and content sharing.
• Azure Active Directory / Microsoft Entra as the identity and access management backbone.
• Azure (hybrid or cloud) platform services for hosting workloads, backups, and managed platform services.

Consolidating these layers brings deep operational integration — single sign‑on, centralized policy, unified support — but also concentrates control and increases the difficulty of migratin# Why identity is the central choke point
Identity is the most strategic component of a digital administration. When user accounts, privilege management, device registration, and conditional access are centralized in a vendor’s cloud identity service, that cloud becomes the administrative heartbeat of government services.

• Microsoft Entra (Azure AD) offers powerful benefits: enterprise SSO, conditional access, device posture, and privileged access management.
• But the default path often favours cloud‑first directory models, and the more an administration relies on a vendor’s control plane for identity, the harder it becomes to execute a rapid migration or to operate independently during an outage or a political dispute.

Microsoft supports hybrid identity — on‑prem Active Directory synchronised with Microsoft Entra and federation models — but hybrid architectures require deliberate design, testing, and governance. They are not automatic defaults. Microsoft’s documentation and hybrid identity tooling (Microsoft Entra Connect, Cloud Sync, federation patterns) make hybrid operation feasible, but each installation’s guarantees depend on configuration, SLAs, and contractual commitments.

Data control and keys: capability vs enforceability​

One of Bojanov’s central concerns is key control: who holds the keys that encrypt government data? Microsoft has progressively offered stronger controls to public‑sector customers:

• Customer‑managed keys (CMK) and HSM integrations let customers control encryption keys for many services and workloads.
• Microsoft has expanded sovereign and hybrid controls in Europe (including the EU Data Boundary implemented in 2025) and announced enhancements to sovereign landings and disconnected operations.

Crucial caveat: the existence of technical controls is not the same as guaranteed operational control. Not all managed services support CMK in identical ways, and contractual language, auditability, and tested migration procedures determine whether a customer truly retains effective control. Pronforceable, auditable key custody, and proof that those controls are operational across the specific services being purchased.

---

The trigger event: ICC, sanctions and the shift toward openDesk​

The debate is no longer hypothetical. In early‑to‑mid 2025 the U.S. administration imposed sanctions on ICC leadership after the court issued arrest warrants that triggered political backlash. Reporting indicates that the ICC’s chief prosecutor found his official Microsoft email account disabled and was forced to move to a non‑U.S. provider. The incident highlighted the reality that U.S. extraterritorial measures can have collateral operational impacts on international organisations that depend on U.S. cloud providers. Major international outlets reported the disruption and its operational effects on the ICC’s work. Soon after, the ICC moved to source a European, sovereign‑oriented alternative. Germany’s Centre for Digital Sovereignty (ZenDiS) — established by the German state to reduce reliance on large foreign vendors — has developed openDesk, a curated open‑source office and collaboration suite designed for public institutions. In late 2025 and into 2026, reports indicated that the ICC would adopt openDesk-based solutions to regain operational autonomy and to place critical services under European legal jurisdiction. ZenDiS public materials confirm the organisation’s mission and claim openDesk as a flagship product aimed at public‑sector sovereignty. Why this matters to Sofia: the ICC case is a concrete demonstration of the political levers that can be exerted against cloud‑dependent institutions. For governments that rely on U.S.-based cloud platforms for identity and mail, the ICC episode underscores the real risk that a political decision made overseas could have immediate technical effects on critical services.

---

Technical mitigations Microsoft offers — and their limits​

Microsoft has added many features meant to address sovereignty and control concerns. They are real and important, but they are mitigations rather than absolute fixes.

• Customer‑Managed Keys (CMK) / BYOK: Microsoft now supports customer key control across many Azure and M365 workloads, and has started migrating legacy BYOK models to a broader CMK framework with explicit timelines for transition. These capabilities reduce vendor access if implemented and audited correctly. Recent Microsoft documentation lays out migration timelines and cautions about workload coverage.
• Customer Lockbox and privileged access governance: mechanisms that require explicit approvals before Microsoft engineers can access tenant data; they raise the bar for provider access but still depend on the contractual scope and audit logging.
• Azure Sovereign and national partner clouds: offerings and roadmaps (Sovereign Landing Zone, Azure Local, dedicated sovereign clouds) provide options to place data and compute under national control or in restricted geographies, sometimes with local operators for governance. These are meaningful for regulated workloads but come with cost and feature parity tradeoffs.

Practical limits and supply‑chain realities:

• Feature coverage is uneven. Some managed services still rely on platform keys unless specific configurations are set and validated.
• Legal and operational gr contract language, audit rights, and independent verification.
• Even with CMK, metadata, control planes, and logs may remain subject to provider operational processes unless those too are specifically contracted or escrowed.

In short: Microsoft provides the tools to harden sovereignty — but those tools must be demanded, contracted, tested and audited before they translate to operational sovereignty.

---

Procurement design: how to buy Microsoft safely (if yrian state proceeds with a Microsoft‑centric framework, the procurement must be engineered to lock mitigations into enforceable obligations. A pragmatic procurement checklist:​

• Functional procurement wording, not brand lock
• Define measurable requirements for identity, email, collaboration, availability and encryption; do not rely on brand names as the functional spec.
• Mandatory, auditable CMK for sensitive systems
• Require hardware‑backed key custody (HSMs), third‑party key escrow options, and independent auditing of key usage logs.
• Explicit exit and egress guarantees
• Contractually require full data export in documented, open formats; mandates for vendor cooperation during migration exercises; staged, contractually scheduled portability tests.
• **Operational SLAs and runbooks that include political‑riskclude SLAs for availability and tested continuity runbooks that cover forced access suspensions, extraterritorial legal actions, or restricted vendor support.
• Independent verification and audit
• Require third‑party verification of claimed controls (CMK coverage, Customer Lockbox logs, access governance) prior to award and periodically thereafter.
• Segmentation and multi‑vendor redundancy
• Avoid a agencies. Keep critical services segmented, with at least some mission‑critical systems on independent infrastructure or under alternative vendors.
• Pilot and staged adoption
• Start with pilots and mandatory migration exit tests in year one; do not commit to a multi‑year blanket adoption until migration capability is proven.

These demands raise short‑term costs, but they are insurance against systemic failure and sudden political or operational cutoffs.

---

Alternatives and complementary strategies​

No single path is without tradeoffs. Options Belarus or Bulgaria should evaluate include:

• Hybrid architectures: keep privileged accounts and critical identity anchors on‑premises or in a federated AD model while using cloud‑managed productivity for general staff. Microsoft supports hybrid identity patterns, but careful design is required.
• Multi‑vendor strategy: split critical services — identity, mail, collaboration, platform — across vendors with federated or bridge mechanisms to avoid a single point of failure.
• Open‑source sovereign stacks: evaluate European open‑source alternatives (ZenDiS/openDesk is a live example) for non‑mission‑critical collaboration and as a strategic option to preserve migration pathways and local control. The ICC’s move toward openDesk is an early, high‑visibility precedent.
• Sovereign hosting and national partner clouds: contract for Azure Local or national partner clouds that provide local control options and explicitly bind operations under local legal jurisdictions. Microsoft has developed “Sovereign Public Cloud” tooling and partnered clouds to address such needs, but capabilities differ by country and workload.

Each option requires investment in local capacity, third‑party auditing, and a long‑term migration budget. Europeans are increasingly funding sovereignty initiatives (ZenDiS and the EU Digital Commons efforts are examples). These programs aim to reduce critical dependence on a single overseas cloud provider; they are not instant replacements but they create real alternatives over time.

---

Political and fiscal calculus​

Centralised licensing often saves money in the short term by consolidating purchases and reducing duplicate ies vendor management. That is the pragmatic argument government officials will present.
But procurement must internalise the full fiscal ledger:

• Cost of enforced CMK and HSMs.
• Cost of independent audits, key escrow, and verified migration tests.
• Budget for pilot migrations and for maintaining parallel, segmented services during phased transitions.
• Contingency funds for emergency migration and legal disputes.
• Political cost of opaque decision‑making: contested procurement can create legal andges that impose delay and transactional cost.

The right balance depends on how willing political leadership is to trade short‑term efficiency for long‑term resilience and sovereement that omits enforceable sovereignty measures risks long‑term economic and operational cost inflation via vendor lock‑in.

---

Notable strengths in Bojanov’s argument — and where nuance matters​

Strengths:

• He reframes an operational procurement as a strategic sovereignty decision, which is precisely how such procurements should be treated.
• He cites practical architecture risk points: identity centralisation, key custody, and cloud control planes — all real elements that materially affect continuity and autonomy.
• He points to a real precedent (ICC) that turns an abstract geopolitical risk into a tangible operational failure that had immediate consequences. That example is useful for policymakers to test worst‑case scenarios.

Nuances and cautions:

• The technical claim that Microsoft “requires all user accounts to be in the cloud” overstates the case. Microsoft recommends cloud identities for cloud services, but it also offers hybrid identity and federation patterns that allow on‑premises anchors and staged migrations; these are real, widely documented options. The difference between a vendor’s recommended design and the set of contractually required configurations matters. This is a point of technical nuance that must be handled in procurement language.
• The assertion that Microsoft “did not offer governments the opportunity to fully control the keys” was true historically in specific product configurations, but Microsoft has expanded CMK and sovereign capabilities in recent years. Still, the protective value of CMK depends on workload coverage and verified implementation — not marketing claims alone. Procurement should verify per‑workload CMK support and contractually require it.
• Some publicly circulated single‑incident narratives (e.g., precisely how and why a given mailbox was disabled) remain politically contested. Multiple reputable news outlets reported that the ICC’s access issues followed U.S. sanctioning measures and involved Microsoft-managed services being affected — but the precise legal and operational chain of authority for a particular mailbox suspension may not be fully public in every detail. Treat those incident descriptions as illustrative and cautionary rather than as incontrovertible proof of vendor collusion.

---

Practical recommendations for Bulgarian policymakers and IT leaders​

• Publish the tender’s technical annexes and scoring matrix publicly before the procurement launches to allow independent review and to avoid future legal challenges. Transparency reduces political risk.
• Mandate audited, enforceable CMK for all sensitive systems and require proof (attested by third‑party audit) before contract signing. Hold the vendor to a documented, per‑service CMK support list.
• Require a tested migration and exit plan in the contract’s first year: the vendor must demonstrate egress procedures, export of active directory objects, mail archives, and configuration manifests, and must cooperate in an independent migration exercise.
• Segment critical services: keep privileged identity anchors and highly sensitive services insulated from the broad consolidation tenancy; favour a hybrid identity posture for privileged accounts.
• Pilot open‑source or EU‑based alternatives (e.g., ZenDiS / openDesk or other mature open‑source stacks) for a portion of collaboration and non‑mission‑critical services as an insurance policy and to stimulate local supplier ecosystems. The ICC’s example demonstrates this pathway’s political and operational feasibility.
• Fund a sovereign roadmap: invest in local hosting, partner cloud relationships, and training so that migration off a dominant vendor is feasible in months, not years.

---

Conclusion​

Bojanov’s warning is not fearmongering — it is a necessary alarm about structural risk. A decision to centralise the state’s server licensing, identity, and productivity platforms with one large overseas provider is both an IT procurement problem and a national strategy problem. Technical mitigations exist: CMK, Customer Lockbox, sovereign clouds, and hybrid identity are all real tools. The policy test is whether those mitigations are converted into enforceable contractual guarantees, audited and tested in the field.
The ICC‑openDesk episode is an instructive, tangible precedent: it shows that political actions can cascade into immediate operational effects for organisations tied to overseas cloud platforms. That should not automatically condemn all use of mature commercial platforms; doing so would leave governments without important security, manageability and productivity advantages. But it is a reminder that procurement must be designed with sovereignty‑minded technical requirements baked in: auditable CMK, tested exit paths, segmented tenancy, and independent verification.
If the Bulgarian procurement process embeds those protections, it can reap the practical benefits of mainstream vendor products while preserving real options and resilience. If it does not, Bojanov’s prediction of long‑term risk is, unfortunately, well founded.

---

Source: fakti.bg Bojanov: A new contract with Microsoft for the state administration is coming, which is risky