Have you ever watched a city from a screen? The morning fog over a river, the crowd at a transit hub, the traffic streaming from one district to another — all of it, through a single dashboard, a single algorithm? Someone is watching. Perhaps someone always has been. But the question has changed: where are those images flowing, under whose law are they being processed — and who is responsible for the data sovereignty of a city?

I. Tehran’s Lesson: The Strategic Risk of Urban Surveillance Infrastructure

According to a Financial Times report citing anonymous sources, Israeli intelligence had penetrated Tehran’s traffic camera network years before Operation Roaring Lion. Those cameras were part of an infrastructure the Iranian regime had built for urban surveillance purposes. The irony is sharp: the system constructed to consolidate the regime’s own control was quietly turned, over the years, into the instrument of its undoing.

Footage was reported to have been encrypted and relayed to servers in Tel Aviv; AI algorithms processed the raw data, mapping the life patterns of Iranian officials — where they went, when, with whom, by which route. When the map was complete, the operation that followed reached its targets swiftly. General Dan Caine’s statements confirm that cyber and space capabilities were integral to the campaign. Not weapons, data. Not fire, pattern.

The war has not ended. Iran survives, and the outcome remains uncertain. Tehran is not a closed file — it is an open one, sitting in front of us.

And on 10 March 2026, one of its pages opened from an unexpected direction.

Michael Rubin, a senior fellow at the American Enterprise Institute (AEI) and former Pentagon adviser, posted in Turkish on his social media account. Rubin has followed regional politics closely since the 1990s and personally handled the Iraq and Iran files at the Pentagon.

His record on Türkiye goes well beyond ordinary academic criticism. After the July 2016 coup attempt — in which 251 people were killed, Parliament was bombed, and the Gülenist organisation’s role was subsequently established through extensive judicial proceedings ending in final convictions — Rubin nonetheless argued that the evidence presented by Turkish authorities was insufficient, opposed the extradition of Fethullah Gülen from the United States, and has for years taken a markedly hard line against Türkiye’s political and security policies. His assessments of Türkiye should therefore be read not as the technical warning of a neutral observer, but as statements coming from a political perspective that is openly adversarial toward Türkiye.

His message, in summary: it is highly likely that traffic cameras in Istanbul and Ankara are similarly accessible. Turkish politicians, drone factory workers, intelligence and military personnel involved in supporting Hamas or Hezbollah or in operations targeting Kurds could have their movements tracked through these cameras — and that information could be shared with relevant actors. He estimated how long such individuals would survive in a potential conflict: a few minutes.

This text, coming from policy circles that are not particularly friendly toward Türkiye, can be read as political provocation, or as a risk notification. From a legal standpoint, that distinction is secondary: a scenario directly concerning the physical safety of Turkish officials was put into the public domain. Rubin offers no technical proof; but he points to an architectural risk grounded in verifiable facts. What are those facts?

II. Istanbul and Ankara’s Traffic Infrastructure: What Do Public Records Show?

On 22 September 2020, while a pandemic held both cities still, Istanbul Metropolitan Municipality (İBB — İstanbul Büyükşehir Belediyesi) signed a 5.1 million dollar grant agreement with the U.S. Trade and Development Agency (USTDA) and American software company SAS Türkiye, for the “Istanbul Transportation and Traffic Excellence Center” project. One month earlier, on 20 July 2020, the Ankara Metropolitan Municipality had signed its own 2.5 million dollar agreement with the same USTDA and SAS Türkiye, for a “Route and Operations Optimization Project.” The scope: public transit routes, journey times, emergency scenarios — the operational backbone of the Turkish capital.

In 2020, cybersecurity awareness in Türkiye had not reached its current level; Law No. 7545 did not yet exist, and secondary regulations were not yet being discussed. This context matters when evaluating the agreements. The question this analysis raises is not a retrospective criticism of those who signed them — it is about an architecture that is still operating today, under a legal framework that remains incomplete.

The sums may seem modest relative to the scale of urban infrastructure. That impression is not wrong, but the structure behind it matters: this was not an ordinary financial grant to be spent at the municipality’s discretion. According to USTDA’s own announcement, the grant supported the deployment of an AI-based analytics platform, to be provided by SAS, within Istanbul’s transportation infrastructure. In the same announcement, USTDA explicitly linked the partnership to “creating unique business opportunities for U.S. industry.“

The project’s stated goals included reducing average journey times and traffic congestion. İBB’s 2021 Annual Report lists some concrete outputs from the project’s first phase: hourly traffic forecasts on main arteries, roughly 5,000 users directed to park-and-ride facilities, the identification of some 350,000 residents without public transit access within 500 metres, and analyses of İSBİKE usage. The report does not, however, contain a comparative impact assessment showing to what extent the originally announced congestion and journey-time targets were met. When İBB responded to allegations in March 2025, it stated that data is stored in its own data center, but offered no assessment of the project’s transportation outcomes either.

USTDA describes itself as the U.S. government’s “first mover” in critical infrastructure development in emerging markets. It operates under the foreign policy guidance of the State Department; its budget justifications state the priorities plainly: “U.S. leadership in critical and emerging technologies” and “service to national security and foreign policy objectives.” SAS, meanwhile, is a longstanding supplier to the U.S. Department of Defense. Its own public sector page states: “SAS’ first customer was the U.S. Federal Government. Today, every cabinet-level department and all branches of the Department of Defense are SAS customers.”

These are not allegations — they are the company’s own public disclosures. Being a supplier does not mean sharing data; but from a legal risk assessment perspective, this relationship cannot be ignored.

III. Smart City Data Sovereignty under FISA 702 and the CLOUD Act

So where is the data from Istanbul and Ankara actually processed?

An important distinction is needed here. SAS Viya is a platform that can run on a range of infrastructures, including Microsoft Azure. But the fact that a software product can run on Azure does not mean that the specific Istanbul deployment does. İBB’s 2021 Annual Report states that the software supplied under the USTDA grant was installed “on servers located within İBB” and integrated into the institution’s existing software management processes. There is therefore no sufficient factual basis for concluding, from Viya’s Azure compatibility and the absence of an Azure region in Türkiye, that the Istanbul deployment sits abroad.

That information matters, but it does not answer the whole question. An annual report is neither a technical architecture document nor an independent security audit. It says nothing about the server and network architecture on which the software operates, whether the vendor holds remote or privileged access, whether telemetry or diagnostic data leaves the environment, who controls the encryption keys, or how vendor access is bounded. Nor is it clear from public documents whether the deployment model reported in 2021 still applies today.

This is where the legal question begins.

Two separate regimes in U.S. law bear on this discussion. FISA Section 702 permits, under specified conditions, the compelled assistance of U.S. electronic communication service providers in acquiring foreign intelligence concerning non-U.S. persons located outside the United States. The CLOUD Act, in turn, allows providers covered by the Stored Communications Act to be required to produce data within their possession, custody or control regardless of where that data is stored. The existence of these regimes does not, by itself, establish that U.S. authorities can access the data in the Istanbul project.

This point matters: the mere use of American-origin software does not mean that Istanbul’s traffic data is open to U.S. authorities under the CLOUD Act or FISA 702. That assessment depends on the vendor’s legal status in the specific service relationship and, above all, on the technical and factual access it holds over the data or the system.

But the cyber sovereignty question does not end there. The presence of a foreign technology vendor in a critical public data infrastructure requires asking what technical and contractual safeguards govern access rights, remote support, telemetry, key management, update mechanisms and vendor dependency. For the Istanbul project, public documents do not answer all of these questions.

IV. Why Have Municipalities Failed to Solve What the Banking Sector Already Has?

Türkiye’s banking sector recognized this risk years ago. BDDK’s Banking Information Systems and Electronic Banking Services Regulation (Article 25, effective 1 July 2020) requires banks to maintain their primary and secondary systems within Turkish territory — including the systems of any cloud service providers used by those banks. A Turkish bank’s customer data cannot be processed on Dutch servers.

But the daily movement data of millions of Istanbul and Ankara residents — where they go every morning, which route they take, where they are at each hour — raises questions whose answers remain unclear but consequential. While data residency in banking is tied to an explicit, sector-specific legal rule, no comparable sector-specific regime subjects foreign technology procurement in municipal transport and mobility systems to equally explicit data residency, access and audit conditions.

There is now a public debate: were the data stolen, who has them, who is responsible? Political framing, investigative language. But behind that debate, a quieter and more durable question remains.

The architecture already contained this risk.

Placing a foreign technology vendor in this critical layer already required asking how these risks were managed architecturally and contractually. Yet the public statements of the regulatory and oversight authorities and of the municipalities do not set out a technical and legal framework that answers the full set of questions on access rights, telemetry, key management, remote support and vendor access.

Whether this transparency gap reflects a choice or a deficiency, both answers are serious in their own right. Public institutions have a responsibility to explain to citizens the technical and legal framework under which public services operate; this transparency is among the most fundamental requirements of democratic accountability.

Lawrence Lessig wrote decades ago: code is law. Whether a cloud platform is used at all and, if so, which one, whether a data localization clause appears in the contract, which encryption protocols were applied — these are all legal decisions. And they were typically made during procurement, in technical specifications, far from legal oversight.

V. Two Systems, One City: KGYS, UYM and the Question of Isolation

Tehran taught us something: urban data infrastructure is a security matter. Traffic cameras, sensors, movement patterns — these are strategic assets as much as technical systems. The legal regime under which they operate may seem like a detail in peacetime.

But at this point, a technical distinction needs to be stated clearly. Istanbul has two separate urban camera layers. The first is the security-focused Kent Güvenlik Yönetim Sistemi (KGYS) — formerly known as MOBESE. This system operates within the General Directorate of Security, under the Ministry of Interior. It is technically the closest equivalent to the system penetrated in Tehran. The second is İBB’s Ulaşım Yönetim Merkezi (UYM) — focused on traffic flow, journey times, sensors, and mobile application integration. This is the system the USTDA-SAS agreement targeted.

İBB stated that data in this system is held in its own data center; if accurate, the FISA/CLOUD Act access risk for this project should be assessed differently. But the boundary between the two systems is less clear in practice than it appears. İBB’s own UYM page documents that the Governor’s Office has real-time access to this system; in emergencies, all systems converge under the AKOM umbrella. A 2022 official document from the Istanbul Governor’s Office also acknowledges that municipal camera systems can constitute alternative data sources outside KGYS.

The legal framework governing this integration is not publicly defined. The conditions under which access to municipal systems is granted, to whom and when, are not established in any public document. Nor is the audit mechanism to which KGYS’s cybersecurity architecture is subject. Rubin’s risk does not reside in a single system — it resides in this entire infrastructure: fragmented, distributed, and interlocking.

VI. Law No. 7545 and the Unanswered Question of Supply Security

Law No. 7545 on Cybersecurity entered into force on 19 March 2025. Roughly a year and a half has passed since then, and the institutional framework has moved: the Cybersecurity Presidency explicitly lists transportation, public services and digital infrastructure among the sectors covered by its critical infrastructure work, and reports that compliance, audit and oversight activities under the Information and Communication Security Guide and the Audit Guide are ongoing.

The more specific problem this article points to nonetheless remains: the public framework does not adequately show which binding conditions foreign technology procurement in critical public IT infrastructure is subject to in terms of data residency, privileged access, remote support, telemetry, encryption key ownership and vendor access; how those conditions are reflected in tenders and contracts; and how they are audited in concrete projects. That is where the debate should now focus. The regulatory window therefore remains uncertain — but it is still open.

Bringing municipal infrastructure explicitly within the critical infrastructure definition, establishing mandatory independent audits for foreign software in public systems, inserting data localization conditions into procurement specifications — these are legal choices, not technical ones — and together they define what data sovereignty means in practice. The cost of delay rises with each passing day.

A note to policymakers and practitioners in emerging markets: the questions raised here are not specific to Türkiye. Any city that has signed a smart infrastructure agreement with a U.S.-based provider — regardless of the project’s stated purpose — faces the same set of questions; how far FISA 702 and the CLOUD Act actually reach depends on the deployment model and the vendor’s factual access, which is precisely why those questions must be asked before signing. The time to ask these questions is before the agreement is signed, not after the cameras are installed.

Rubin wrote a scenario. The scenario is technically plausible. Law’s task is to make that scenario impossible — or at minimum, to make the architecture that prevents it mandatory.

The war has taught us something else as well: sovereign software, independent infrastructure, domestic data centers — these are no longer questions of technology policy but of security policy. Emerging markets that continue to outsource their urban data architecture to foreign jurisdictions are not just making a technical choice. They are deciding, often without realizing it, whose law governs their cities. That question deserves a separate piece — and an urgent one.

Correction – [16 September 2026]

The original version of this article, published on 17 March 2026, contained an inference, drawn from SAS Viya’s ability to run on Microsoft Azure and the absence of an Azure region in Türkiye, that the Istanbul deployment was hosted on Azure.

On re-examination following a technical critique, İBB’s 2021 Annual Report was found to state that the software supplied under the USTDA grant was installed on servers located within İBB. That inference therefore lacked sufficient factual basis and the relevant section has been corrected; the passages on the grant structure and on the project’s reported outputs have been revised accordingly. This correction was applied to the Turkish version on 6 September 2026 and to this English version on [16 September 2026].

The annual report addresses the location of the deployment but not remote access, telemetry, privileged access, encryption key ownership or the scope of vendor access. The correction therefore does not alter the article’s central question: in critical urban data infrastructures, data sovereignty must be assessed not only by where data is held, but by who can access the system and the data, under what authority, and subject to what oversight.

I am grateful for the critique that prompted this re-examination.

Yazdır