Federal Law No. 406-FZ, which came into force in December 2023, requires Russian services to verify local users through Russian infrastructure. Instead of Google and Apple, only phone numbers issued by domestic carriers, Gosuslugi (the Russian governmental public services portal), and the Unified Biometric System are now accepted.

Penalties for non-compliance came later. On Tuesday, June 9, 2026, the State Duma (Russia’s lower house of parliament) passed amendments to the Administrative Code that impose fines on services that verify users using non-local infrastructure. On Friday, June 25, 2026, Vladimir Putin signed the proposed amendments.

Mechanics of the law

The law technically prohibits the use of foreign identifiers; if a service redirects a user to accounts.google.com or appleid.apple.com during new account creation via OAuth 2.0, that constitutes a violation.

The same prohibition applies to phone numbers issued by foreign telecom companies when used as registration identifiers. The status of foreign email addresses as login credentials remains uncertain. Some legal experts argue the ban covers authorization through a foreign provider (the “Sign in with Gmail” button) but not the use of an email address itself as a login (a detailed legal analysis is available on Habr).

The law defines four permitted methods:

• a mobile phone number issued by a Russian mobile operator;
• the Unified Identification and Authentication System (ESIA, the Gosuslugi portal);
• the Unified Biometric System (EBS);
• any other information system owned by a Russian citizen or a Russian legal entity with at least 50% Russian ownership, provided it meets applicable information security requirements.

The last option may cover several Russian platforms, particularly VK ID and the identity systems of major Russian banks. Whether each of them actually meets the law’s requirements must be confirmed separately. Still, the law itself does not define the confirmation procedure or the responsible authority (as set out in its text).

Positive moments

The law has no retroactive effect. Accounts created through Google or Apple before December 1, 2023, remain valid without any restrictions.

Sanctions for non-compliance apply to service operators, not to users, according to Sergei Boyarsky, chair of the State Duma Committee on Information Policy, Information Technologies and Communications.

Penalties

A new Administrative Code article (preliminary article number 13.55; the final number will be established upon official publication) introduces fines:

Category	First violation	Repeat violation
Individuals	10,000–20,000 rubles (about $133–$266)	20,000–40,000 rubles (about $266–$532)
Officials	30,000–50,000 rubles (about $399–$665)	60,000–100,000 rubles (about $798–$1,330)
Legal entities	500,000–700,000 rubles (about $6,650–$9,310)	1,000,000–1,400,000 rubles (about $13,300–$18,620)

Open questions

Several questions about the law remain unanswered:

• How will regulators check whether a specific site is compliant?
• When will active enforcement actually begin?
• How will edge cases be handled? For example, services with a predominantly foreign audience, or internal corporate systems?
• How will Roskomnadzor (RKN, Russia’s federal communications regulator) determine a user’s location: by IP address, by the service’s own declaration, or by any other means?
• Will violations be counted cumulatively or individually?

That last point deserves a closer look. The law uses the term “authorization,” while related terms (“identification,” “authentication,” “registration”) from Federal Law No. 149-FZ are absent. RKN may rely on publicly available sources (dictionaries and local regulatory acts) when doing inspections. RKN has not issued any official guidance on which sources it intends to use. This leaves a wide margin for interpretation.

The professional community is discussing the risk that RKN may treat each authorization session as a separate violation. Standard Administrative Code practice classifies a violation by the failure to fulfill an obligation, not by the number of sessions. So, this interpretation would be unusual and would likely be challenged in court. There is no established case law yet to help assess these risks.

There is a real possibility that a service could be fined once for each user who registered through Gmail.

How user verification works under the new rules

Before the law came into force, Russian services could delegate user verification to foreign providers. For example, Google or Apple would receive a request, verify the user’s identity, and return a token, all outside Russian jurisdiction.

From December 1, 2023, new registrations must use one of the Russian verification methods. Each method has its own data and its own infrastructure. The law does not require services to disable Google and Apple for accounts created before December 1, 2023. However, it does not prohibit doing so voluntarily. Ozon (one of the major Russian marketplaces), for instance, disabled foreign identity providers for all users.

SMS verification via a Russian carrier

The user confirms ownership of a phone number issued by a Russian telecom company. The carrier logs each OTP delivery: the phone number, the timestamp, and the requesting service. This is SMS-OTP, a one-time code delivered through the carrier’s network.

Russian SMS aggregators are available for implementation, accessible via HTTP interfaces or the SMPP v3.4 protocol: SMS.ru, SMSAero, SMS Pilot, Stream-Telecom. All of them are connected to Russian companies. In addition to classic SMS OTP, there is a flash-call method: the code is communicated as the last digits of an incoming call, with no SMS message sent. This is faster and cheaper, and it does not create a log entry containing the code at the carrier level. Not all carriers and devices support this method.

The status of one-time codes from authenticator apps such as Google Authenticator is unclear. TOTP authenticators have a different technical nature. Their status as a standalone authorization method under 406-FZ has not been defined. Under Federal Law No. 374-FZ, Russian carriers are required to store connection metadata for three years and provide it to authorized authorities on request via SORM (System for Operative Investigative Activities, Russia’s lawful interception infrastructure).

ESIA (Unified Identification and Authentication System)

ESIA functions as a federal IdP: it stores passport data, SNILS (individual insurance account numbers), and registration addresses verified at account creation. When a user authenticates through ESIA, the portal records which third-party service was accessed and when; this is standard practice for any identity provider implementing OAuth 2.0. A new ESIA regulation, mandatory for all new integrations from 2025 onward, requires connected systems to use KS3-class cryptographic protection tools (a high-assurance level of cryptographic information protection certified by the FSB, Russia’s Federal Security Service) and to obtain accreditation. Organizations connected under earlier versions of the regulation must complete the transition by the end of 2026.

Yandex ID documentation is available at yandex.ru/dev/id/doc/ru; mobile apps have access to a dedicated LoginSDK toolkit. Integration follows the standard Authorization Code Flow in OAuth 2.0, which is technically identical to Google and Apple, with only the endpoints changed. OAuth 2.0, as a protocol, is not prohibited by law. What is prohibited is using it through foreign endpoints (accounts.google.com, appleid.apple.com).

EBS (Unified Biometric System)

The EBS stores biometric templates collected through authorized organizations. At login, the system compares the user’s biometric data against records in the database.

How services are implementing the new requirements

Major platforms began transitioning before the fines were introduced. A few examples:

• Ozon disabled Apple ID login, noting that fewer than 1% of its users relied on that method.
• Litres (a Russian e-book retailer) stopped supporting Apple and Google ID logins from April 22, 2024; users without an alternative method were directed to customer support.
• VK Play sent users a warning about the upcoming change to login methods.

The new requirements led to the emergence of a market for Russian identity providers. Yandex ID, VK ID, Sber ID, and T-ID (T-Bank) are positioning themselves as replacements for foreign identity providers in B2B and fintech. Developers rate Yandex ID as the most seamless authorization method for Russian audiences. They also recommend VK ID for projects with a clear social component.

Despite the activity of major companies, market participants estimate that some platforms did not meet the transition deadline (originally extended to January 1, 2025, by Gorelkin’s bill), creating legal exposure once the Administrative Code amendments take effect. Since those amendments are not yet in force, it remains to be seen whether the potential fines against late adopters materialize.

Services accessible from Russia that offer only Google or Apple to new users technically violate the law. Compelling foreign legal entities to comply is technically difficult for RKN, and there are no publicly documented enforcement precedents.

To gauge how much the law affects a given service, three parameters are worth checking: 

• the share of traffic from Russia, 
• whether the corporate structure includes Russian legal entities, 
• whether the service is listed in Russian registers or has any formal interaction with Russian regulators. 

High scores on even one of these signals a need to either add Russian authentication methods or restrict access from Russian IP ranges.

Both options have consequences. Adding Russian methods creates a legal connection to Russian infrastructure and may trigger data localization requirements. IP-based blocking does not eliminate legal risk if the corporate structure includes a Russian legal entity. For organizations subject to sanctions, both options require a separate legal assessment.

Recommendations for services and developers

Several scenarios remain legally undefined.

• Email as a login without OAuth (entering an address and password directly, with no redirect to an external provider, including addresses on foreign domains): the legal status of this method is uncertain. Some lawyers consider it acceptable; others classify it as prohibited.
• Authorization of users located outside Russia, and corporate federation through foreign identity management systems (Active Directory, Okta, and similar tools), is not explicitly addressed by the law. This concerns internal employee authentication, not public user authorization via Google or Apple.

A special case: TOTP

• TOTP as a second factor on top of a permitted primary login method is technically not prohibited. Its status as a standalone first factor under 406-FZ is undefined but, importantly, not explicitly banned.
• To reduce the volume of identity data exposed via SMS verification, consider using TOTP as a second factor. This reduces dependence on the SMS channel and mitigates risks tied to carrier-level vulnerabilities. The example of open-source implementations compatible with RFC 6238 (Request for Comments): Aegis (Android) and FreeOTP (Android, iOS). Both require no third-party account and send no data to the app developer. Using an SMS aggregator instead of a direct carrier connection reduces the volume of metadata visible to individual carriers, but does not eliminate logging within the SORM system.

Additional considerations

A VPN masks an IP address but does not erase the phone number tied to the account at registration. If the account was created through ESIA, the user’s activity remains linked to their Gosuslugi account regardless of the connection used. In other words, changing IP addresses does not prevent identification. The user’s identity is already bound to the account at the registration data level.

The shift to SMS verification expands the attack surface. Intercepting OTPs via vulnerabilities in the SS7 (Signaling System No. 7) protocol is technically complex but has been documented as a real attack vector against public figures and cryptocurrency wallet holders. SMS bombing becomes a new tool. An attacker triggers mass registration requests, flooding the target number with a continuous stream of verification codes. A compromise of an SMS provider that serves multiple platforms could allow an attacker to intercept codes across all platforms simultaneously.

The risk structure has changed. Previously, compromising a single Google account gave access to all linked services. However, one provider with a high security baseline was doing the protecting. Now, a phone number serves as the login across many independent Russian platforms with very different security standards.

Observable signals and monitoring

The law changes Russian services’ authentication infrastructure in ways that are observable from the outside. The transition can be tracked by analyzing OAuth flows. The compliance signal: new registrations require a phone number or redirect to esia.gosuslugi.ru, while existing accounts can still log in via Google or Apple. This method has a limitation: if a service has implemented phone-based login without an OAuth redirect, the transition will not be visible in flow analysis and will require direct registration testing.

A separate monitoring question: the accessibility of ESIA from outside Russia. Some users abroad no longer have an active Russian phone number. Checking whether esia.gosuslugi.ru loads from different countries will show whether foreign users can register on Russian services at all. Keep in mind that testing the portal’s HTTP reachability is not a substitute for testing the full authentication flow, which requires a Russian phone number or an existing ESIA account. This kind of measurement covers DNS resolution, TCP connection establishment, and an HTTP/HTTPS request, followed by a comparison with a control unblocked node, according to OONI (Open Observatory of Network Interference) Web Connectivity methodology.