TelecomPaper reported the partnership on August 27, one day after MULTIFACTOR and Selectel announced it. Both companies describe the result as a way to add a second factor without deploying and operating a separate MFA platform. Selectel’s published documentation fills in the operational details that the announcement does not: customers buy licenses, configure the service in MULTIFACTOR’s management console, and remain responsible for policy and user administration.
For Windows and infrastructure administrators, that makes this a procurement and integration change rather than a switch that automatically hardens every Selectel workload. It can be useful where an organization needs a managed identity layer in front of exposed remote-administration services, but it does not remove the need to close public RDP exposure, apply least privilege, or separate privileged accounts.
The service is for customer systems, not the Selectel account itself
Selectel already requires two-step authentication for users of its own control panel by default after registration and profile completion. Its documentation says users can obtain codes through an authenticator application or email, while only the Account Owner can disable the second factor. In other words, the new MULTIFACTOR offer does not introduce MFA to the Selectel console; it addresses the systems a customer operates behind or alongside the provider’s infrastructure.
That difference is material for an IT team reading the partnership announcement. Selectel’s built-in account protection covers access to resources through its management plane. MULTIFACTOR is positioned as an external service that can enforce an added factor for access to an organization’s Windows hosts, VPN gateways, SSH endpoints, VDI deployments, and other corporate applications.
The vendor’s documentation specifically lists RDP among the remote-access scenarios. That makes the service relevant to organizations running Windows Server workloads in Selectel’s cloud or data centers, particularly where administrators and contractors still rely on remote desktop access. But MFA belongs in a layered design: a public-facing RDP port protected only by a password and one-time code remains a more exposed design than a private subnet reached through a controlled VPN or bastion host.
Selectel’s own security guidance makes a similar operational recommendation for Windows servers: avoid using a public IP address for RDP, place servers on private subnets, and provide controlled access through a VPN gateway. Adding MFA may reduce the value of stolen passwords, but it is not a substitute for reducing the number of reachable administrative endpoints.
Documentation shows the Cloud Director path was already defined
The August 26 partnership announcement presents the availability of cloud MULTIFACTOR as new. Yet Selectel’s public documentation had already described a MULTIFACTOR integration for its VMware Cloud Director-based public cloud by July 15. The guide lays out a SAML single sign-on configuration, with MULTIFACTOR acting as the identity service used to apply two-factor authentication to selected Cloud Director users.
This does not prove customers could previously buy the service through Selectel under the same commercial terms. It does show, however, that the technical integration was documented weeks before the partnership press release. The more precise reading is that Selectel has turned a supported integration into a formal, provider-supplied security offering with licensing and access to MULTIFACTOR’s administrative console.
The Cloud Director flow is also narrower than a blanket statement that a tenant now has MFA everywhere. Selectel documents two authentication paths in VMware Cloud Director: its local user database and SAML SSO. MULTIFACTOR is configured on the SSO route, while local authentication continues to operate in parallel.
That parallel local-login path creates an implementation task that should not be delegated to a checkbox exercise. An administrator needs to identify which users retain local accounts, determine whether those accounts can perform privileged actions, and decide how accounts are created, disabled, and reviewed. If administrators leave a powerful local account available outside the SSO policy, the new MFA route may protect only part of the access surface.
SAML configuration means identity work remains with the customer
The integration is not an agentless magic layer placed automatically in front of every service. Selectel’s Cloud Director instructions require an administrator to create a SAML application in the MULTIFACTOR console, select an identity provider, exchange SAML metadata with VMware Cloud Director, enable the SAML identity provider in Cloud Director, import users, and assign roles.
The guide supports Active Directory as an identity-provider option during SAML application setup. It also describes options to register users in MULTIFACTOR on first authorization and to block Cloud Director access until a user has completed self-enrollment for 2FA. Those are valuable controls, but they need deliberate rollout planning. Automatic user registration can simplify onboarding; it can also turn an incomplete identity inventory into an access-control problem if group membership, role assignment, and offboarding are not settled first.
For a Windows shop, the key question is where authentication is actually terminated. A Cloud Director administrator signing in through SAML can be covered by the documented integration. A Windows Server administrator opening a direct RDP connection needs an appropriate MULTIFACTOR integration in the RDP access path as well. A user accessing an internally hosted web application may need another connector or SAML/OIDC configuration entirely.
The announcement says MULTIFACTOR can secure RDP, VPN, VDI, and SSH, but it does not publish a Selectel-specific deployment matrix identifying which integrations are included, which require separate connectors, or which work across every Selectel product. Organizations should treat the formal support claim as a starting point and verify the exact application, protocol, operating system, and identity-store combination before committing to migration.
What Selectel is selling—and what it is not managing
Selectel’s service documentation is unusually direct about the split of responsibility. Selectel provides licenses to use MULTIFACTOR and access to the MULTIFACTOR control panel. The customer configures and administers two-factor authentication policies, applications, and users.
That division matters in incident response. The customer, rather than Selectel, will own the day-to-day controls that determine whether a departed contractor is disabled, whether an emergency account is monitored, how a lost authenticator is recovered, and whether authentication events are reviewed. The service documentation says actions are recorded in the MULTIFACTOR event log, but the public materials do not specify log retention, export formats, SIEM integrations, or which events are available to customers.
Pricing is similarly absent from the announcement. Selectel says the service is sold as monthly licenses with a minimum of five licenses, with Standard and Extended plans and potential additional charges for SSO connectivity. It does not publish a price list in the announcement or the general service overview. Procurement teams therefore cannot compare it cleanly with Microsoft Entra ID tiers, Duo, Okta, self-hosted Keycloak deployments, or other MFA services using public figures alone.
MULTIFACTOR says its product is listed in Russia’s software registry under No. 7046 and holds FSTEC certificate No. 5039; Selectel repeats those identifiers in its service documentation. Those credentials may matter to organizations subject to Russian compliance requirements, but certification should not be read as an automatic determination that a particular customer deployment meets every regulatory obligation. Scope, hosting architecture, data classification, and the surrounding controls still matter.
The missing security detail is factor strength
The available Selectel documentation for the Cloud Director workflow says a one-time code is sent to the MULTIFACTOR application after the user signs in through SSO. Its general service page describes a second factor selected by the administrator, but the partnership announcement does not state which factor types are included with the Selectel offering, whether phishing-resistant FIDO2 security keys are available, or whether push approvals, device binding, and number-matching protections are supported in this package.
That omission is significant because “MFA” describes a category, not a uniform security outcome. One-time passcodes can substantially improve protection against reused or stolen passwords, particularly for RDP and VPN access. They are less resistant than origin-bound, phishing-resistant authentication methods when a user is lured into entering credentials and a code into a convincing proxy site.
Administrators evaluating the offer should therefore ask for the supported-factor list and recovery procedure before rollout. They should also establish a break-glass design that is tightly controlled, logged, tested, and separated from ordinary administrator accounts. The provider’s own control-panel recovery documentation illustrates why recovery processes deserve scrutiny: losing factor access is an operational reality, and an overly permissive reset path can weaken the protection MFA was intended to add.
Selectel and MULTIFACTOR have delivered a potentially useful way for Russian organizations to procure and host an MFA platform without building the underlying service themselves. The immediate work for customers is less dramatic but more important: map every privileged Windows, VPN, and cloud-management login; route the intended paths through the policy; identify the parallel local paths that remain; and verify that the purchased factor is strong enough for the systems it will protect.
