We started checking these sites back in early September. At that time, the DEG portal (remote electronic voting, from the Russian distantsionnoye elektronnoye golosovaniye) also opened from servers. By September 18–19, according to an update of the same analysis, it worked reliably only from Russian home addresses. We cannot establish exactly when access was closed. We only know that it happened between early September and the voting days.

What is happening

Date	What happened
June 6, 2026	Researcher hyperion_cs publishes an analysis of a new restriction scheme on Habr (a Russian IT community platform): the restrictions cover entire subnets and autonomous systems of Russian data centers
June 11, 2026	Hosting providers link mass outages to a configuration update of the TSPU (Technical Means of Countering Threats), the hardware deployed by Roskomnadzor (RKN, Russia’s internet and media regulator) to filter traffic
June 15, 2026	Habr publishes an analysis of the “fingerprint freeze” mechanism: the connection breaks after the transport connection is established, at the encrypted handshake stage
June 24, 2026	The Ministry of Digital Development (Mintsifry) states that DEG information resources have been added to the “allowlists,” as reported by Parlamentskaya Gazeta (the Russian parliament’s newspaper)
September 9, 2026	The Riposte runs a test: the DEG portal opens from all seven vantage points tested, while election commission websites do not open from abroad or from a server in Moscow
September 12, 2026	The Riposte tests the DEG app: at five of seven vantage points, measurements hit a technical error on the service side.
September 16, 2026	Date of the last change to the documentation of Selectel (a major Russian hosting provider), which states that access to e-government subnets from the provider’s infrastructure is blocked
September 18, 2026	In Melitopol and Berdiansk (Ukrainian cities occupied by Russian troops), authorities restrict mobile internet for the election period, until September 22, as reported by MK (Moskovsky Komsomolets), citing the Ministry of Digital Development of the Zaporizhzhia region
September 18–19, 2026	A repeat check for an update of The Riposte’s analysis: the DEG portal and the Gosuslugi portal (Russia’s state services portal) work reliably only from Russian residential addresses.
September 19, 2026	Rostelecom records two cases of damage to backbone fiber-optic communication lines (VOLS) in the Far East, as reported by Parlamentskaya Gazeta, citing RIA Novosti; company president Mikhail Oseevsky called it “organized sabotage”
September 19, 2026	The Moscow City Election Commission (Mosgorizbirkom) reports a technical failure in the DEG system on the first day of voting
September 20, 2026, 15:59 MSK (Moscow time)	Ella Pamfilova reports more than a thousand waves of DDoS (Distributed Denial of Service) attacks and no disruptions to the availability of the servers of the CEC (Central Election Commission)
September 20, 2026, 16:20 MSK	Our team adds election sites to the measurement rig, along with control sites that are known to be blocked and known to be accessible, and starts measurement rounds at twenty-minute intervals.
September 20, 2026, 21:50 MSK	Mintsifry announces the final turnout on the federal DEG platform: 90.87% of registered participants
September 21, 2026, 17:12 MSK	Our team starts recording the connection failure stage in each measurement round

What The Riposte’s September check showed

In early September, we tested seven vantage points: home internet in Europe and in St. Petersburg, four servers (in Moscow, St. Petersburg, Germany, and Finland), and a commercial virtual private network (VPN) service with a Russian exit node. This set differs from the vantage points of the current measurement rig, so you can compare them only in general terms, not point by point.

In early September, the DEG portal still opened from everywhere: “vybory.gov.ru and mos.ru opened from all seven nodes, in both browsers, without a single caveat. Election commission websites, however, already opened only from home and corporate networks in Russia. The Gosuslugi portal failed to open only from the server in Germany. We tested the DEG app on September 12 on an Android device: at five of seven points, it returned a technical error and worked only over home internet.

“By the voting days, the picture had changed. On September 18 and 19, the federal electronic voting website (vybory.gov.ru) and ‘Gosuslugi’ opened and worked reliably only from Russian home IP addresses.” The same analysis says that from foreign IP addresses “in most cases you will get a timeout, a 502 error, or a connection reset,” and that logging in through a Russian VPN depends on the specific network.

Mechanics

The connection to the DEG portal gets reset, and the commission website stays silent

Our measurement rig checked both sites from eleven vantage points (ten in Russia and one in Germany). It counted as a failure any case where the site did not respond to a request. We added the election sites to monitoring in the afternoon of September 20, before polling stations closed, so the rig has no earlier data on them. Alongside them, the rig checked sites known to be blocked and sites known to be accessible. The former show whether the tool can detect interference at all. The latter confirm that the network as a whole is working.

Throughout the evening of September 20, both election sites stayed silent. They did not respond to any of the hundred checks from Russian vantage points or to any of the ten from the German one.

Meanwhile, the known-accessible sites responded without failures, and the known-blocked sites did not open from Russia but opened from Germany. So the network was working, and the tool could detect interference.

Starting September 21, our rig began recording the step at which the connection breaks. At nine of the ten Russian vantage points, the connection to the DEG portal first opened and then broke at the moment the requested site name became visible. At the tenth Russian vantage point and at the German one, the connection did not open at all. The election commission website did not respond even once at any of the eleven vantage points, including the German one.

The new observation phase lasted more than a day, from the evening of September 21 to the evening of September 22. During this time, the commission website never responded to a request from a server or from abroad, and the connection to the DEG portal broke in almost every round. The failure outlasted election day and persisted for two more days after polling stations closed.

An earlier failure on the Gosuslugi portal

From September 18, the Gosuslugi portal increasingly failed to respond to the rig’s requests. We should not tie this directly to the election, though. People use Gosuslugi to log in, but they vote on a different site with different infrastructure. Also, a foreign developer website began experiencing degraded responsiveness at the same time as Gosuslugi, which does not fit the theory that someone started blocking access to a government service. The monitoring list did not yet include control targets known to be blocked, so we do not know whether the tool could detect interference at all. You will find the detailed figures in the section for censorship researchers.

What happened? Three hypotheses

Hypothesis one: the service itself rejects connections from hosting addresses to protect itself from automated traffic

The test rig’s data undermines this hypothesis. The connection to the DEG portal breaks only after the requested site becomes visible, while this kind of protection usually triggers earlier. In addition, one of the ten Russian vantage points behaves like the German one: the connection does not open there at all, even though it is a server just like the other nine. The cause seems to lie in the specific path to the site rather than in the type of vantage point.

Hypothesis two: the hosting provider itself cuts outbound access

Selectel’s documentation page about blocked ports and internet resources says this directly: “Access to public e-government subnets from Selectel’s infrastructure is also blocked. For example, the Gosuslugi portal and related services are located in such a subnet. You can submit an unblocking request. We review each request individually but cannot guarantee unblocking.” Selectel updated the page on September 16, two days before the vote, and the page refers to the Gosuslugi portal, not to vybory.gov.ru.

One of the rig’s vantage points sits in Selectel’s network, and the Gosuslugi portal did not respond there during the entire September 21–22 period. A failure at this vantage point does not require government filtering; the hoster’s own restriction is enough. The same vantage point produced most of the Gosuslugi failures even before the vote. This means that a single hoster (rather than the site itself) created the background failure rate. So at this vantage point, the second hypothesis holds for the Gosuslugi portal. For the DEG portal, it remains unverified: the Selectel document does not mention vybory.gov.ru, and the DEG portal also stays silent at vantage points of other providers.

Hypothesis three: filtering equipment on the path to the site (rather than the service itself) breaks the connection

Hosting providers linked the mass outages of June 2026 to this equipment, as reported by Cableman (a Russian telecom news site), citing RBC. Selectel pointed to a possible connection with new TSPU filtering rules, and Beget and Timeweb (Russian hosting providers) recorded “intermittent” outages. The article contains no direct quotes from the companies themselves; it is a paraphrase.

Researcher hyperion_cs analyzed the mechanics of the third hypothesis on Habr. According to his description, the censor decides based on the server address, or more precisely its subnet or an entire autonomous system (AS), meaning the network of a single provider. In his words, “entire subnets and even ASes are affected, including those of popular Russian data centers (e.g., Selectel, Yandex.Cloud, Cloud.ru, and others).” The rig’s data does not refute this hypothesis, because a filter on the route could break the connection in exactly this way, once the site name is visible.

One detail does not match the June description of the “fingerprint freeze.” There, the connection hung without an explicit reset, while here something actively terminates it. This does not rule out interference on the route, since the reset could be another variant of the same rule.

What we could not find in the public domain

We searched open sources for confirmation of the three hypotheses, and four lines of inquiry produced nothing. Only Selectel has a note about e-government subnets: the documentation and terms of nine other providers (Timeweb, Beget, Yandex Cloud, Cloud.ru, VK Cloud, reg.ru, Hostkey, RuVDS, and Serverspace) contain no similar notes. No hoster mentions vybory.gov.ru or election commission websites, and all the notes we found concern the Gosuslugi portal, which is a different host.

We have not yet found any statements from the CEC or Mintsifry about how the “allowlists” performed specifically on September 18–20. There is neither an admission of failures nor a denial. There are also no public technical measurements of the failure mechanism itself for September 2026: all the analyses of the mechanism we found date from June.

We checked the OONI database. For September 17–21, 2026, it contains no measurements from Russia for the domains vybory.gov.ru, cikrf.ru, izbirkom.ru, and gosuslugi.ru. A query to the OONI public API for each of the four domains returns a zero count and an empty result list. This matters for our question because OONI collects measurements from volunteers’ devices, meaning home and mobile connections rather than data centers. Internet Outage Detection and Analysis (IODA, a system for detecting internet outages) does not measure the availability of individual sites at all. It only shows the overall connectivity of countries and networks, so it cannot tell us anything about the election domains.

What do officials say?

On September 20, CEC chair Ella Pamfilova spoke of “more than 1,000 waves of DDoS attacks on Russian infrastructure involved in the electoral process.” According to her, the attacks came with “attempts to find and exploit vulnerabilities in the election infrastructure of the federal DEG platform (vybory.gov.ru), the Unified Portal of State and Municipal Services (gosuslugi.ru), the CEC of the Russian Federation (cikrf.ru), and the domain zone of election commissions (izbirkom.ru).” She went on: “We have learned to repel these attacks; they were detected in time and filtered by security tools.”

Pamfilova mentioned filtering, but it is still unclear whose filtering it was: the service’s own or that of the equipment on the path to it. Pamfilova also said: “No instances of damage or disruption of server availability were recorded.” For Russian home connections, this does not contradict the observations, since according to The Riposte, the DEG portal and Gosuslugi worked reliably from such addresses on September 18–19. From server and foreign addresses, access was closed, and the CEC said nothing about that.

Less is known about the Moscow failure. Mosgorizbirkom chair Olga Kirillova reported a technical failure on the first day of voting. That was all.

Measurements from data centers have no bearing on voting availability, the objection goes, because voters go online from home or mobile connections, and the service may treat such addresses quite differently. The Riposte update answers this objection only partly. According to the same analysis, on September 18–19 the DEG portal and Gosuslugi worked reliably specifically from Russian home addresses. So the restriction our team found most likely did not affect the ordinary voter voting from home in Russia.

The rig’s own data does not directly cover home and mobile connections: all eleven of its vantage points sit in hosting networks. Official figures also indirectly support the objection: final turnout on the federal DEG platform was 90.87%, with more than 3.6 million people voting, RIA Novosti reported on September 20, 2026. But turnout is calculated from the number of registered participants rather than the full voter roll, so it does not measure how available the service was to a random user.

Recommendations for censorship researchers

These recommendations are for research groups and media outlets that build their own measurements instead of retelling other people’s statistics. Each of them relies on what our rig showed (or failed to show) during these days.

• Run a positive control at the same moment as the target measurement. A known-blocked target measured from the same vantage points and in the same rounds distinguishes “no interference detected” from “the tool would not have seen interference.” In our set, the controls behaved differently depending on the vantage point. From the German point, all four targets responded without a single failure. From the Russian points, failures were constant, and only at one St. Petersburg point were there noticeably fewer for two of the four targets (62 and 65 out of 153). The control failures themselves also differed: in some cases the site name did not resolve, in others the connection was not established, and in others the handshake broke.
• At one Moscow vantage point, three controls returned a certificate that failed validation (46, 39, and 76 times out of 153, respectively). This indicates interception of the encrypted connection at that specific point, and the DEG portal was never intercepted this way there. The negative control, example.com, responded 1,680 times out of 1,683 attempts, and the three misses were single rounds at two vantage points.
• The step change on the federal identification portal shows the cost of skipping a control. From September 17 to 20, its failure rate grew every day: 13.0% (15 of 115) on September 17, 24.3% (27 of 111) on the 18th, 42.2% (49 of 116) on the 19th, and 44.4% (52 of 117) on the 20th. We calculated the rates in a consistent 03:00–16:00 MSK window across nine vantage points with a continuous history. A day later, a foreign developer website joined the portal: 0% on September 18, 9.4% (11 of 117) on the 19th, and 23.1% (27 of 117) on the 20th. The picture varied across vantage points: three failed consistently, three failed intermittently, and four did not fail at all. The median latency of successful responses stayed flat, so the data does not support the theory that a vantage point’s link degraded. No positive control confirms any of these days: it appeared in the set only in the afternoon of September 20, after the counting window.
• Record the failure stage and the handshake outcome. First, the client and server open a transport connection over the Transmission Control Protocol (TCP). Then comes the encrypted handshake over the Transport Layer Security (TLS) protocol. At its start, the client sends the first message, the ClientHello, with the name of the requested site. Failures vary: an active connection reset with a reset (RST) packet, or silent dropping of packets with no response. So each record needs the tool’s return code, the failure stage (before connection, during the handshake, after the response), and the handshake outcome. Our team introduced this kind of record on September 21. Only this record made it possible to distinguish the handshake reset on the DEG portal from the complete absence of a connection on the election commission website: without it, the two cases look the same in the statistics. In our data, the connection to the DEG portal broke in almost every round, 152–153 times out of 153 at each of the nine vantage points. On the evening of September 20, before we recorded the stage, the break took 68 to 570 milliseconds at most vantage points, while the known-blocked controls broke the connection more slowly, in 2.6–7.8 seconds. In the first 17 rounds of the new phase, the time to failure ranged from 30 milliseconds to 5.6 seconds. Throughout the observation period, no target returned an encrypted handshake error message (TLS alert). This weakens the theory that the portal requires Russian encryption under the national GOST standard (Russia’s state cryptographic standards): a server with such a requirement would have sent a handshake error. A caveat: the set does not include a target that is known to send such an error, so we have not tested this conclusion in the field.
• Track domain name resolution failures separately. At two vantage points, the domain name often failed to resolve for several targets at once, and the identification portal appeared among these failures more often than other targets: in 17 of 68 and 13 of 24 cases. Three deviations from the overall failure pattern for the election commission website came from the same name resolution failure at one vantage point.
• Split the measurement pool by individual vantage point. In our set, a single St. Petersburg vantage point produced the background failures on the identification portal before September 18: it accounted for 95.4% of all failures in that period. A separate check showed that at this same point, the Gosuslugi portal did not respond in any of the 153 rounds on September 21–22. The vantage point sits in autonomous system 49505, which belongs to Selectel JSC according to the Hurricane Electric registry, and this provider’s documentation directly explains such a failure.
• Add a residential or mobile vantage point. It distinguishes “the service does not let data centers in” from “data centers get a response, but regular connections do not,” although it does not show where exactly on the path to the service the failure occurs. In the check for The Riposte, our team used both home and server vantage points, so the update of the analysis could show the difference between them. A rig of eleven server and foreign vantage points cannot show such a difference.
• Record the characteristics of the reset packet itself. The packet’s time to live (TTL) and other header fields help determine who sent the reset: a device on the traffic route or the server itself. This requires packet capture, which is a different class of tool from ordinary port polling.

Recommendations for circumvention tool developers

These recommendations are for developers of circumvention transports and clients. They rely on how the failure mechanism at the DEG portal differs from the one described in the June analyses.

• Test hypotheses about trigger thresholds yourself. In June 2026, the author darkisdark analyzed the “fingerprint freeze” mechanism on Habr. According to his description, “the freeze happens after the TCP handshake completes, during the TLS handshake or immediately after it,” and it works by dropping packets for about 120 seconds without an explicit RST packet. The author himself calls the trigger threshold and the list of suspicious networks unconfirmed: “the thresholds (350–400 ms / 60 s, ~120 s, 600 s penalty, ‘>3 handshakes’) have not been cross-checked by independent measurements; they are working hypotheses,” and the “named list of ‘suspicious’ Russian ASNs comes from Telegram sources reprinting each other, without packet dumps.” An architecture built around specific thresholds from such analyses fully inherits the risk that they are wrong.
• Distinguish two classes of failure in your telemetry. The mechanism our team recorded at the DEG portal does not resemble this “freeze”: instead of hanging, the connection gets actively reset during the handshake, after the client has named the site. This does not rule out interference on the route, since the reset could be another variant of the same rule. A client that logs an active reset and silent packet dropping as the same error will not help tell them apart.
• Do not assume that equipment behaves the same across operators. The same analysis states directly that each operator deploys filtering equipment in its own way, and what triggers on one operator’s network may not trigger on another’s. So a test on one network transfers to another only as a hypothesis.
• Keep in mind that suspicion falls on the entire subnet. According to the June analyses, hosting on the addresses of large Russian data centers in itself becomes a signal for analysis. Here, choosing a hosting location is as much an architectural parameter as choosing a transport.

The bottom line

Russians abroad had difficulty voting. According to the check for The Riposte, the portal worked from Russian home connections but was closed to server and foreign addresses.

We still do not know who exactly breaks the connection: the service itself or a filter on the way to it. Our team is finishing its own client for direct measurements from home connections and will publish its data separately.During the State Duma elections on September 18–20, 2026, the Remote Electronic Voting Portal (DEG) and the election commission website blocked access from servers and foreign IP addresses. The DEG portal worked from Russian home addresses, as the editors’ check showed.