Fortinet FortiAuthenticator Cloud in Dubai, UAE
FortiAuthenticator Cloud brings FortiAuthenticator identity and authentication capabilities into a Fortinet-managed cloud service. For UAE organisations, the practical question is no longer simply whether the service can support SSO, MFA, passwordless authentication, RADIUS or certificate-oriented access workflows. Buyers also need to decide whether starting or extending FortiAuthenticator Cloud is sensible in light of its announced lifecycle milestones and Fortinet’s direction toward FortiIdentity Cloud for SaaS identity services.
FourTeck can help translate user counts, current authentication methods, FortiGate or FortiSASE use, directory design, application federation requirements and migration constraints into a bill of materials and an appropriate transition plan.
Fortinet has announced 30 September 2026 as the End of Order milestone for FortiAuthenticator Cloud. New purchases, extensions and migration planning should therefore be evaluated against FortiIdentity Cloud and other FortiAuthenticator deployment choices rather than treated as a routine long-term cloud subscription decision.
Direct answer for buyers evaluating FortiAuthenticator Cloud
FortiAuthenticator Cloud is Fortinet’s cloud-based FortiAuthenticator offering for identity and access management, including central authentication, SSO, adaptive authentication, passwordless methods and integrations used across hybrid environments. It is relevant to organisations that want FortiAuthenticator capabilities without maintaining the equivalent authentication appliance on site. Before proceeding, buyers should confirm user quantity, subscription band, required authentication methods, FortiToken or FortiIdentity Cloud entitlement, directory and application integrations, current Fortinet infrastructure, migration effort and support requirements. Because Fortinet has announced the service’s End of Order milestone for 30 September 2026, any new or extended purchase should also include a documented lifecycle decision and a comparison with FortiIdentity Cloud or an alternative FortiAuthenticator deployment.
What the service does
FortiAuthenticator Cloud provides a managed cloud environment for authentication and identity functions based on the FortiAuthenticator engine. Its role is to help an organisation establish a consistent identity layer between users and the applications, VPNs, network services and Fortinet systems they need to access. Rather than running a physical FortiAuthenticator appliance, the customer consumes a user-based cloud subscription and administers the identity configuration through the service.
The platform supports identity federation for SSO, modern web authentication protocols, adaptive authentication, passwordless methods, RADIUS-based authentication, certificate management and other access functions. The exact workflow depends on the connected services and current licensing. It should therefore be designed as part of an identity architecture, not purchased simply because an organisation already uses FortiGate.
Who should consider it now
The remaining FortiAuthenticator Cloud purchase window is most relevant to organisations with an existing deployment, a near-term expansion, a renewal decision, or a project whose technical dependencies are already tied to FortiAuthenticator Cloud functionality. It may also be considered where a current architecture uses features that must be mapped carefully before moving to FortiIdentity Cloud.
A new greenfield buyer should compare alternatives before standardising on the service. Fortinet’s announced lifecycle means procurement teams need to evaluate not only feature fit but also the time and effort required for a later transition. Organisations expecting a long SaaS lifecycle, multi-region cloud-native design or future feature expansion should specifically review FortiIdentity Cloud capabilities and gaps against their requirements before making a commitment.
Lifecycle notice: this is now part of the purchase decision
Fortinet announced in July 2026 that FortiAuthenticator Cloud is reaching End of Order. The published milestone is 30 September 2026 for End of Orders, the last date to purchase a new maintenance contract, and the last date to extend an existing maintenance contract. Fortinet’s announcement states a product support expiry of 30 September 2027, or the end of an existing or renewed contract when that date is later. Buyers should confirm the exact entitlement and contract dates for their own account because lifecycle policy and purchased terms determine the practical support window.
Fortinet is encouraging customers to evaluate FortiIdentity Cloud as its SaaS-based identity direction. That does not mean every FortiAuthenticator Cloud configuration can simply be swapped one-for-one. Feature mapping matters. The comparison published by Fortinet in its lifecycle communication shows differences in areas such as FSSO, SCIM roles, RADIUS/RADSEC timing, 802.1X, certificate management and other functions depending on the FortiIdentity Cloud release. A transition therefore needs an application-by-application and authentication-flow review rather than a name change on a renewal order.
FourTeck can assist with a lifecycle-oriented requirement review: identify which FortiAuthenticator Cloud functions are actually in use, separate mandatory features from legacy configuration, check user and token licensing, and compare the target state with FortiIdentity Cloud, FortiAuthenticator appliance, virtual machine or supported public-cloud deployment options.
Business problems the platform can address
Fragmented authentication
When VPN, network, SaaS and internal applications each rely on separate login logic, policy administration becomes difficult. FortiAuthenticator Cloud can act as a central identity and authentication point for supported services, reducing the number of independent authentication silos that administrators must manage.
Weak user verification
Password-only access creates avoidable exposure. The platform supports MFA, adaptive authentication and passwordless FIDO-based methods, although the token or FortiIdentity Cloud entitlement required for the selected MFA workflow must be confirmed separately under current licensing.
Too many application passwords
Identity federation can provide SSO to supported cloud and on-premises services using protocols such as SAML and OAuth/OIDC. This can simplify access for end users while giving the organisation a central place to manage identity relationships and authentication policy.
Cloud preference without an IAM appliance
Some organisations want FortiAuthenticator functionality but do not want to operate a dedicated authentication appliance in each environment. The cloud service addresses that deployment preference, while the approaching lifecycle milestone makes transition planning an equally important part of the decision.
Core capability band
Is FortiAuthenticator Cloud a sensible fit?
| Requirement | Suitable when | Confirm before ordering |
|---|---|---|
| Cloud-based FortiAuthenticator | You already depend on FortiAuthenticator Cloud functionality or have a short-term requirement aligned with its remaining lifecycle. | Whether a new FortiIdentity Cloud design is more appropriate for the expected service life. |
| MFA for users | The required token, push, email, SMS or other MFA workflow is technically supported. | Current FortiIdentity Cloud or FortiToken Mobile licensing and any hardware-token requirement. |
| Application SSO | Applications support a compatible SAML or OAuth/OIDC federation model. | IdP/SP roles, claims, group mapping, certificates, provisioning and cutover steps. |
| RADIUS or 802.1X | Network devices and access policies are designed around supported RADIUS/RADSEC and 802.1X functions. | Whether the intended replacement platform supports the same functions on the required timeline. |
| Long-term greenfield SaaS IAM | Only after lifecycle alternatives have been compared and a migration path is accepted. | FortiIdentity Cloud feature fit, migration effort, user licensing and any dependencies not yet available in the target release. |
Verified product and purchasing information
FortiAuthenticator Cloud is a service rather than a hardware appliance, so processor, port count, rack size and similar hardware rows are not useful buying criteria. The information below focuses on items that affect subscription selection, identity design and lifecycle planning.
| Brand | Fortinet |
| Product | FortiAuthenticator Cloud, formerly known as FortiTrust Identity |
| Product type | Cloud-based identity and access management / authentication service |
| Platform basis | Built on the FortiAuthenticator engine and delivered as a cloud subscription |
| Licensing basis | Per-user subscription with user-band SKUs |
| 100–499 users | FC2-10-ACCLD-511-02-DD |
| 500–1,999 users | FC3-10-ACCLD-511-02-DD |
| 2,000–9,999 users | FC4-10-ACCLD-511-02-DD |
| 10,000+ users | FC5-10-ACCLD-511-02-DD |
| SSO / federation | SAML and OAuth/OIDC supported; API capabilities are also documented by Fortinet |
| Authentication features | Adaptive authentication, MFA capability and passwordless FIDO/passkey support; entitlement depends on current licensing |
| Network identity functions | RADIUS including RADSEC and 802.1X are supported in the FortiAuthenticator Cloud feature set referenced by Fortinet’s 26.2 lifecycle comparison |
| Certificate management | Supported in FortiAuthenticator Cloud; confirm migration requirements if moving to another platform |
| Tenant model | A single FortiAuthenticator Cloud instance is provided per FortiCloud account |
| Configuration migration | Automatic migration between a FortiAuthenticator appliance and FortiAuthenticator Cloud is not supported; configuration must be recreated by the administrator |
| End of Order | 30 September 2026 according to Fortinet’s July 2026 announcement |
| Support lifecycle | Fortinet states product support expires 30 September 2027, or at the end of an existing/renewed contract if later |
| UAE availability | Contact FourTeck to confirm current order eligibility, user band, term and vendor lead time before the lifecycle milestone |
Licensing, token and entitlement dependencies
The most important procurement detail is to separate the FortiAuthenticator Cloud user subscription from the authentication method entitlement. Current Fortinet 26.2.a documentation states that FortiToken licenses are not included in the FortiAuthenticator Cloud subscription. It also states that, from the referenced FortiAuthenticator Cloud release path, customers configuring MFA must purchase separate FortiIdentity Cloud licenses, or alternatively purchase FortiToken Mobile perpetual token licenses and import those into FortiAuthenticator Cloud. Hardware tokens are a separate purchase where required.
This matters because older materials and legacy contracts may describe token or SMS arrangements differently. A buyer should not assume that a previous FortiTrust Identity or earlier FortiAuthenticator Cloud entitlement applies to a new order. The correct approach is to inspect the current contract, activation entitlement, number of users, token method, SMS requirement and renewal date, then build the quotation around the exact current vendor SKU and service version.
User-band licensing also means the count should reflect the actual population that needs the service. The published subscription bands begin at 100 users for the FC2 FortiAuthenticator Cloud band and extend through tiers for 500–1,999, 2,000–9,999 and 10,000 or more users. The quantity, term code represented by the SKU suffix and any co-term requirement should be validated when quoting.
For businesses already using FortiIdentity Cloud alongside FortiAuthenticator Cloud, the relationship between the two products must be reviewed carefully. Fortinet’s recent FAQ explains that FortiIdentity Cloud is now decoupled from FortiAuthenticator Cloud and requires its own license. This is especially relevant when planning a transition to FortiIdentity Cloud as the long-term SaaS identity platform.
Confirm these license items
- Exact number of licensed end users
- Required subscription term and co-term date
- FortiToken Mobile, hardware token, push, email or SMS requirement
- Whether FortiIdentity Cloud entitlement is already owned
- Existing legacy FortiTrust or FortiAuthenticator Cloud contracts
- Renewal or migration deadline before 30 September 2026
- Applications and network services that cannot tolerate authentication changes
- Support and migration assistance required from FourTeck
A practical purchase and transition journey
Inventory identities and applications
Count users and identify every application, Fortinet device, VPN, network service, directory and certificate workflow that currently depends on the identity platform. Separate business-critical flows from low-risk or legacy integrations.
Map authentication methods
Document SAML, OIDC, RADIUS, RADSEC, 802.1X, certificate, FIDO, token, push, SMS and email use. This reveals which functions require dedicated licensing or may affect the replacement-platform decision.
Choose the lifecycle path
Decide whether the business has a justified reason to purchase or extend FortiAuthenticator Cloud before End of Order, or whether a direct move to FortiIdentity Cloud, FortiAuthenticator VM, appliance or supported public-cloud deployment is more appropriate.
Quote, test and schedule
Confirm the bill of materials, test critical integrations, plan user communication and establish a cutover or renewal timeline. Where migration is required, allow for configuration recreation and application revalidation rather than assuming a fully automatic transfer.
Federated SSO for cloud and on-premises applications
Use identity federation to reduce separate application login paths while keeping protocol and claim design under control.
FortiAuthenticator Cloud supports SSO scenarios using modern federation protocols including SAML and OAuth/OIDC. In practice, this can allow an organisation to operate FortiAuthenticator Cloud as an identity provider or intermediary in supported application authentication flows. The business value comes from centralising how user identity is asserted to applications rather than maintaining a unique credential experience for every service.
The design work happens in the details. Each service provider needs the correct entity identifiers, redirect or assertion consumer URLs, signing certificates, claim names, group information and access policy. Some applications use SAML while newer services may prefer OIDC. A mixed estate may therefore require several federation patterns. Identity teams should also document what happens when a user’s department changes, an account is disabled, a certificate expires or an application changes its federation metadata.
For a lifecycle transition, the important question is not simply whether the replacement platform also supports SAML or OIDC. It is whether the existing application configuration can be reproduced with compatible IdP behavior, claims, provisioning and user experience. SCIM capabilities, for example, differ between FortiAuthenticator Cloud and the FortiIdentity Cloud release described in Fortinet’s lifecycle comparison. That difference may affect user provisioning or deprovisioning architecture even though both platforms can provide SSO.
FourTeck can help buyers create an application federation inventory, identify the protocols and claims in use, and define which applications should be tested first. This reduces the risk of choosing a subscription based only on a high-level feature name while overlooking the exact identity behavior needed by business applications.
MFA, adaptive authentication and passwordless access
Authentication strength should be selected by risk and user workflow, then matched to the correct entitlement.
FortiAuthenticator Cloud supports multifactor authentication, adaptive authentication and passwordless FIDO/passkey approaches. These capabilities can help an organisation move beyond a simple password check by asking for additional proof of identity or using phishing-resistant authentication methods where supported. The correct design depends on the population being protected: administrators, remote-access users, office staff, contractors and application users may have different risk profiles and device availability.
Adaptive authentication can reduce unnecessary prompts when policy determines that a sign-in is occurring under trusted conditions, while challenging higher-risk attempts. Passwordless methods can remove the need to type reusable passwords in supported scenarios. Mobile tokens and push workflows can provide a familiar MFA experience for many users. However, technical support for a method is not the same as having that method included in the base FortiAuthenticator Cloud subscription. Current Fortinet documentation separates FortiAuthenticator Cloud licensing from FortiToken and FortiIdentity Cloud entitlements, so the bill of materials must reflect the actual method selected.
User experience should be tested as part of procurement. Teams need to understand enrollment, token activation, device replacement, recovery procedures, offline scenarios, lost phones, help-desk resets and onboarding for new employees. If SMS or email is used, policy owners should consider the security level appropriate to the protected application and any service-specific quota or entitlement rules.
For organisations moving toward FortiIdentity Cloud, the MFA migration path deserves explicit planning. Some token transitions can be simplified, but the licensing relationship and supported method still need validation against the current Fortinet release and contract. FourTeck can assist with user counts, authentication-method mapping and quotation preparation so that token costs are not discovered only after the identity platform has been selected.
RADIUS, 802.1X and certificate-oriented access
Network authentication dependencies can be more difficult to replace than web SSO and should be mapped early.
FortiAuthenticator Cloud has been used for network access and RADIUS-based authentication as well as application identity. Fortinet’s 2026 lifecycle comparison lists RADIUS including RADSEC, 802.1X authentication and certificate management among FortiAuthenticator Cloud capabilities. These functions can be important in enterprise networks where identity must be checked before a user, device or remote connection receives access.
RADIUS is commonly involved in VPN authentication, administrative access or network access control. 802.1X can be part of wired or wireless access policy. Certificates may support user, device or service trust depending on the design. When these features are used together, the identity platform becomes part of a broader control chain that includes switches, wireless controllers, FortiGate, endpoints, certificate enrollment and directory information. A migration must therefore be tested against actual network devices and policies rather than treated as a portal-only change.
This is particularly important because Fortinet’s FortiAuthenticator Cloud to FortiIdentity Cloud comparison shows that some network identity functions were at different levels of availability or roadmap maturity in the FortiIdentity Cloud release cited in the announcement. Buyers planning a near-term transition should confirm the current release status at the time of migration, because roadmap items can change and a capability that is absent today may become available later.
A practical assessment should list every RADIUS client, shared secret, certificate dependency, policy condition, VLAN or group mapping, failover expectation and authentication timeout that can affect access. FourTeck can include this inventory in migration planning and help determine whether the new target should be FortiIdentity Cloud, a FortiAuthenticator appliance or VM, or another supported design.
Ideal business environments and real use cases
Existing Fortinet-heavy networks
Organisations using FortiGate, FortiClient, FortiSASE or other Fortinet products may value a central identity service that fits established authentication flows. The relevant question is which integrations are in production and whether they are supported by the target platform after the lifecycle transition.
Hybrid application estates
Businesses running a mix of SaaS and internal applications can use federation to reduce isolated login systems. SAML and OIDC compatibility should be checked application by application, including claims, certificates and provisioning behavior.
Remote and VPN access
FortiGate and FortiClient VPN authentication can be tied to stronger user verification. Buyers should confirm the primary authentication source, RADIUS or federation design, MFA method, emergency-access procedure and user enrollment plan.
Network authentication projects
Where 802.1X, RADIUS/RADSEC or certificate management is part of wired or wireless access, FortiAuthenticator Cloud may already be deeply integrated. Those dependencies should be mapped before moving to a cloud-native replacement.
Renewal and lifecycle projects
Existing customers approaching a renewal can use the lifecycle event as a structured point to clean up dormant users, outdated federation objects, unused token assignments and legacy applications before selecting the next identity platform.
Multi-site UAE organisations
A central identity service can support users across sites without requiring one dedicated FortiAuthenticator appliance per location. Network reachability, directory connectivity, resilience and regional service requirements still need to be validated.
Integration and operational considerations
Identity infrastructure sits in the login path, so availability, change control and operational ownership are important. Fortinet documents FortiAuthenticator Cloud as a managed service with data-center monitoring and disaster-recovery behavior. Its current FAQ also describes automatic failover and failback mechanisms. Even with a managed cloud platform, customer-side dependencies such as DNS caching, internet reachability, firewalls, directory access, application configuration and endpoint behavior can affect the user experience.
Administration should be assigned to a controlled FortiCloud account with documented ownership and recovery procedures. Fortinet states that FortiAuthenticator Cloud provides a single instance per FortiCloud account rather than a multi-tenant model. Organisations with separate subsidiaries, legal entities or delegated administration requirements should consider how that model fits governance before purchase.
Directory integration should also be planned carefully. Existing Active Directory, LDAP or cloud identity sources may remain the authoritative user record while FortiAuthenticator Cloud performs authentication or federation functions. The design should define where users are created, how groups are synchronized, which attributes drive policy, and how disabled accounts are handled. For applications, certificates and metadata should have renewal ownership so an expired signing certificate does not create an avoidable outage.
For operational teams, logging and troubleshooting responsibilities should be agreed before rollout. Authentication failures can originate in the identity provider, a token service, a directory, RADIUS client configuration, application federation, network reachability or a user device. A useful deployment therefore includes a support runbook, escalation contacts, test accounts and a controlled emergency-access method appropriate to the organisation’s security policy.
Migration planning: FortiAuthenticator Cloud is not a one-click move
Fortinet’s current FAQ states that configuration cannot be automatically migrated between a FortiAuthenticator appliance and FortiAuthenticator Cloud; the configuration must be recreated by the administrator. This is an important planning point for customers considering a move to an appliance, VM or other FortiAuthenticator deployment. Even where individual token or user transitions can be simplified, the overall authentication configuration should be treated as a migration project.
Start by exporting or documenting the current logical design: realms, local and remote users, directory links, RADIUS clients, SAML applications, OIDC clients, certificates, authentication policies, portals and any Fortinet product integrations. Then decide what should be reproduced, modernised or retired. Rebuilding every legacy object exactly as it exists can carry technical debt into the new environment.
If the target is FortiIdentity Cloud, perform a feature-gap review rather than assuming equivalent function names imply equivalent behavior. Fortinet’s lifecycle notice explicitly compares the platforms and shows both common features and differences. Confirm the current FortiIdentity Cloud release because items shown as roadmap in the July 2026 comparison may have changed by the date of your migration.
Migration sequencing should protect critical access. Pilot with non-critical applications or a controlled user group, validate login and fallback behavior, then move high-impact services. Keep change windows, DNS behavior, certificate validity, token activation and user communication in the plan. FourTeck can help shape the sequence and quotation scope around the actual number of integrations rather than treating migration as a generic installation task.
Questions to resolve before requesting a quotation
The answer determines the FortiAuthenticator Cloud subscription band and may affect the replacement-platform tier.
List token, push, FIDO/passkey, SMS, email, RADIUS, SAML, OIDC, certificate and 802.1X requirements.
The End of Order milestone changes the recommendation depending on whether the service is already operational.
Identify critical VPN, Wi-Fi, network access, admin authentication and SaaS applications that need controlled cutover.
Share current FortiAuthenticator Cloud, FortiIdentity Cloud, FortiToken and support entitlements to avoid duplication.
The date should account for vendor lifecycle milestones, testing, procurement approval, user communication and integration work.
Procurement and evaluation checklist
How FourTeck can assist
FourTeck can help UAE organisations turn an identity requirement into an orderable and supportable scope. This includes clarifying whether FortiAuthenticator Cloud is already deployed, checking the user band, reviewing current subscription and token entitlements, identifying integration dependencies and determining whether the project should extend the existing service or move toward FortiIdentity Cloud or another FortiAuthenticator deployment.
For migration-oriented projects, assistance can include requirement discovery, bill-of-material guidance, configuration-scope planning, test sequencing and coordination around installation or cutover activities. The exact service scope depends on the environment and should be included in the quotation rather than assumed.
Explore related FourTeck technology services or review the wider security product portfolio.
What to send for an accurate quote
Share the number of users, current vendor SKUs if known, expiry date, authentication methods, FortiCloud account structure, existing FortiGate or FortiSASE use, directory type, application federation count and any required migration date. If the request is for an extension before End of Order, include the current contract term and renewal information.
If you are comparing FortiIdentity Cloud, list any functions that cannot be lost, especially RADIUS/RADSEC, 802.1X, FSSO, SCIM direction, certificate management or unusual application integrations. This makes the comparison technically meaningful instead of relying on generic product descriptions.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability and order eligibility for FortiAuthenticator Cloud. Because the service has an announced End of Order milestone on 30 September 2026, availability is not only a question of vendor lead time; it also depends on whether the requested new subscription, extension or maintenance action is permitted under the product lifecycle and whether the required contract can be completed within the applicable milestone.
For a quotation, FourTeck can review the destination, user count, subscription term, current licenses and migration requirement. Installation or configuration support should be defined separately if needed. A cloud service does not require shipment of a physical FortiAuthenticator appliance, but identity integration still involves technical work such as directory connection, federation configuration, RADIUS client setup, certificate handling, user enrollment and testing.
No fixed stock, activation date or migration completion date should be assumed before the exact requirement is confirmed. For projects where the lifecycle window makes FortiAuthenticator Cloud unsuitable, FourTeck can help compare Fortinet solutions in the UAE and identify a more sustainable identity path.
Dubai, Abu Dhabi, Sharjah and Ajman project coverage
FourTeck can coordinate requirement review and quotation discussions for organisations in Dubai, Abu Dhabi, Sharjah and Ajman as part of one UAE identity project rather than treating each office as a separate product decision. Multi-site buyers should provide the total user population, branch architecture, central directories, FortiGate or VPN topology, cloud application list and any different authentication requirements between locations. Where configuration or migration assistance is requested, the scope can be planned around the actual technical work and agreed delivery method. Current product availability, licensing, vendor lead time and any onsite activity remain subject to confirmation after the environment and lifecycle requirements are understood.
GCC Availability
FourTeck can assist businesses planning FortiAuthenticator Cloud renewals, remaining eligible orders or identity migrations across GCC markets, including the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain and Oman. The useful starting point is a common regional identity inventory: destination country, number of users, existing FortiAuthenticator Cloud or FortiIdentity Cloud contracts, subscription expiry, authentication methods, Fortinet integrations, directory sources and target deployment schedule. This allows the commercial and technical requirement to be evaluated consistently across branches without assuming every country has the same licensing, service or project conditions.
Product availability, license eligibility, delivery schedules, service visits, project scope and vendor lead times can vary by country, model, quantity and requirement. The announced FortiAuthenticator Cloud End of Order date also means buyers should not delay lifecycle validation. FourTeck can support requirement review, license selection, quotation coordination, configuration-scope planning, migration discussion and renewal guidance, but the exact regional fulfilment and support arrangement should be confirmed for each project. Share the destination country, exact product or replacement service, quantity, license term, deployment location and expected timeline so an appropriate option can be prepared.
Africa Availability
Organisations in Africa evaluating FortiAuthenticator Cloud should treat the current lifecycle as part of regional procurement planning. FourTeck can help businesses review existing subscriptions, identify the user population, map token and MFA requirements, assess SSO and RADIUS dependencies, and compare a remaining eligible FortiAuthenticator Cloud action with FortiIdentity Cloud or another FortiAuthenticator deployment. This can be especially useful for organisations with headquarters or shared IT operations in the UAE and branches in markets such as Kenya or Uganda, where one identity design may serve several business locations.
Availability and fulfilment may depend on the destination, subscription SKU, quantity, license region, vendor lead time, deployment scope and local project conditions. FourTeck does not assume local inventory, immediate activation, customs outcomes or country-wide onsite coverage. Buyers should share the destination country, exact requirement, quantity, preferred deployment schedule and any configuration, migration or support expectations. For broader regional planning, review FourTeck Africa technology solutions or FourTeck Kenya for regional coordination context.
Related options to evaluate before committing
FortiIdentity Cloud
Fortinet’s recommended SaaS identity direction for customers moving beyond FortiAuthenticator Cloud. Compare current feature support, token inclusions, multi-region design and migration requirements against the functions you use today.
FortiAuthenticator appliance or VM
Suitable when the organisation prefers dedicated FortiAuthenticator deployment control or needs functions that fit the appliance/VM model. Configuration recreation and infrastructure sizing should be included in migration planning.
FortiGate identity integration
Where the project primarily protects firewall administration, VPN or network access, review the FortiGate authentication architecture and determine which identity service is actually required. See Fortinet firewall options in Dubai.
Migration and configuration support
For customers with many RADIUS clients, applications, certificates or tokens, professional migration planning may be as important as the replacement license. Scope discovery, testing and user communication before quotation.
Why businesses contact FourTeck for this decision
The main value of a specialist discussion is requirement clarity. FortiAuthenticator Cloud now sits at the intersection of technical fit, current licensing and lifecycle timing. A buyer can easily obtain a product name but still miss the difference between the base user subscription, token entitlement, FortiIdentity Cloud licensing, application federation work and the cost of a future migration.
FourTeck can help organise those questions into a practical bill of materials and project scope. That may include confirming the relevant user band, identifying existing licenses, comparing FortiIdentity Cloud, checking compatibility requirements, estimating the number of application and network integrations that need work, and defining whether configuration, migration or support services should be included in the quotation.
This approach is intended to reduce wrong-product purchases and incomplete orders, not to guarantee that one Fortinet option fits every environment. Buyers can also learn more about FourTeck technology services and company information before starting a requirement review.
What buyers are trying to resolve before they choose a cloud identity path
A buyer searching for FortiAuthenticator Cloud today is often trying to answer several questions at once: Is this the cloud version of FortiAuthenticator? Does it replace an on-prem appliance? Is MFA included? How is it licensed? Can it handle SSO for Microsoft, SaaS or internal applications? Does it work with FortiGate VPN users? How difficult is migration? And, because of the 2026 lifecycle announcement, should a new project still purchase it at all? These questions are connected. The right answer comes from understanding the existing identity architecture rather than picking a product from one feature line.
FortiAuthenticator Cloud is delivered as a cloud service, while FortiAuthenticator VM is deployed and operated in the customer’s chosen virtual infrastructure. Cloud service consumption can reduce appliance administration, but a VM may give the organisation more deployment control and may be a better fit when lifecycle, feature or architecture requirements point away from the retiring service.
FortiAuthenticator Cloud uses user-based subscription bands, so a meaningful quote requires the active user count and term. Token or FortiIdentity Cloud requirements must be added according to the selected MFA method. A headline per-user web price is not a complete project cost because implementation, migration, additional authentication services and regional commercial terms can differ.
For SSO, buyers should first list the applications they actually want to federate. A generic statement that a service supports SAML or OIDC does not prove that every application will integrate without effort. Each application has its own metadata, redirect URLs, certificate expectations, user identifiers, group attributes and role mapping. Some organisations also need automated provisioning with SCIM. Those details become especially important when comparing FortiAuthenticator Cloud with FortiIdentity Cloud, because the platforms may support a common protocol but differ in role, direction or release maturity.
For network access, search questions often revolve around RADIUS and 802.1X. If FortiAuthenticator Cloud is providing authentication to FortiGate, switches, wireless infrastructure or VPN systems, the replacement platform must be evaluated against those same clients. Administrators should capture RADIUS client definitions, policies, group mappings, certificates and expected failover behavior. This is more precise than asking whether the new product “supports RADIUS” because the operational design around the protocol matters.
For MFA, current licensing deserves special attention. Fortinet’s latest FortiAuthenticator Cloud FAQ separates the FortiAuthenticator Cloud subscription from FortiToken licensing and explains the current FortiIdentity Cloud relationship. Buyers who used FortiTrust Identity years ago may remember a different bundle. Therefore, renewal planning should begin with the current entitlement certificate and active contract rather than relying on how the service was packaged in a previous generation.
Another common concern is whether moving from an appliance to the cloud service, or back from cloud to an appliance, is automatic. Fortinet states that configuration migration is not automatic and that configuration must be recreated by the administrator. That should change how a project is budgeted. Count the number of integrations and policy objects, not only the number of users. Ten thousand users with two simple application integrations may be easier to migrate than five hundred users with dozens of RADIUS clients, complex certificates, custom portals and many SAML applications.
Businesses also ask whether the service is multi-tenant. Fortinet’s current FAQ states that only one FortiAuthenticator Cloud instance is provided per FortiCloud account. If a group wants isolated administration for several subsidiaries or customer environments, this should be reviewed against governance requirements. The answer may influence whether the organisation keeps separate FortiCloud accounts, adopts FortiIdentity Cloud’s different architecture or chooses another deployment model.
Finally, the lifecycle question should be answered in business terms. An existing customer may have a valid reason to extend a contract before 30 September 2026 to gain time for a controlled transition. A new customer with no dependency on FortiAuthenticator Cloud may be better served by starting with the target platform. FourTeck can help turn this decision into a comparison that covers user count, features, licensing, migration workload, support timing and the applications that must remain available throughout the change.
Decision questions buyers should ask before the next step
Should we renew FortiAuthenticator Cloud or move now?
Base the decision on dependency and time. If critical functions currently rely on FortiAuthenticator Cloud and the target platform needs more validation, a permitted extension before End of Order may provide a controlled transition window. If this is a new deployment, compare FortiIdentity Cloud and other FortiAuthenticator deployment models first. Confirm the current vendor order policy and contract dates before assuming an extension is available.
Do we need FortiIdentity Cloud licenses for MFA?
Current Fortinet documentation says the FortiAuthenticator Cloud subscription does not include FortiToken licenses. It describes separate FortiIdentity Cloud licensing for the current MFA relationship, with FortiToken Mobile perpetual licenses as an alternative path in supported scenarios. Ask FourTeck to verify the exact entitlement for your service version, user count and required authentication method.
Can we move configuration directly from our FortiAuthenticator appliance?
Fortinet states that automatic configuration migration is not supported between an appliance and FortiAuthenticator Cloud. Plan to recreate and validate the configuration. Use the migration as an opportunity to remove unused objects and document active integrations. The effort depends more on configuration complexity than on the product license alone.
What should we test before changing identity platforms?
Test representative SSO applications, VPN access, RADIUS authentication, 802.1X where used, token enrollment, passwordless flows, certificate-dependent services and account disablement. Include failure scenarios such as unavailable directories or expired certificates. A small controlled pilot can reveal integration assumptions before the change affects the whole user population.
How do we size a quote if user numbers are changing?
Start with current active users and realistic growth through the requested term. FortiAuthenticator Cloud has published user bands, so crossing a band can affect SKU selection. Also count token users separately if the selected MFA licensing requires it. For acquisitions or seasonal users, explain the expected peak and co-term requirement so the quotation can be structured correctly.
What information should procurement collect from IT?
Procurement should request user count, current SKU and expiry, authentication methods, application list, Fortinet integrations, directory type, target deployment date and migration scope. This prevents a quote from covering only the base subscription while omitting tokens, configuration services or a required replacement-platform license.
Frequently asked questions
What is Fortinet FortiAuthenticator Cloud?
It is the cloud-based FortiAuthenticator offering, built on the FortiAuthenticator engine and delivered as a subscription service for identity and authentication functions. It can support central authentication, SSO, MFA-related workflows, adaptive authentication, passwordless methods and network access use cases depending on configuration and licensing.
Is FortiAuthenticator Cloud still orderable in 2026?
Fortinet has announced 30 September 2026 as the End of Order milestone. Until then, eligibility for a new order or extension should be confirmed through the current vendor channel and contract rules. Buyers should also evaluate FortiIdentity Cloud because Fortinet is directing SaaS identity customers toward that platform.
When does FortiAuthenticator Cloud support end?
Fortinet’s July 2026 lifecycle announcement states product support expires on 30 September 2027, or at the end of an existing or renewed contract when that date is later. Your actual entitlement should be checked against the purchased contract and Fortinet lifecycle policy.
Are FortiToken licenses included with the current FortiAuthenticator Cloud subscription?
Current Fortinet 26.2.a documentation says FortiToken licenses are not included in the FortiAuthenticator Cloud subscription. It describes separate FortiIdentity Cloud licensing for current MFA use, with FortiToken Mobile perpetual token licensing as another supported option. Confirm the exact method and entitlement before ordering.
Does FortiAuthenticator Cloud support SSO?
Yes. Fortinet documents SSO and identity federation using standards including SAML and OAuth/OIDC. Application compatibility still needs to be validated because each service can have different metadata, certificate, claim, user-provisioning and policy requirements.
Can FortiAuthenticator Cloud be used for RADIUS and 802.1X?
Fortinet’s current lifecycle comparison lists RADIUS including RADSEC and 802.1X among FortiAuthenticator Cloud capabilities. If these functions are important, document the exact network clients and policies because replacement-platform support and release timing must be checked before migration.
Is FortiAuthenticator Cloud multi-tenant?
Fortinet’s 26.2.a FAQ says no: a single FortiAuthenticator Cloud instance is provided per FortiCloud account. Organisations that need isolated administration for multiple entities should review how this model fits governance and compare alternative architectures where necessary.
Can configuration be migrated automatically from a FortiAuthenticator appliance?
No automatic appliance-to-cloud configuration migration is documented. Fortinet states that the configuration must be recreated by the FortiAuthenticator Cloud administrator, and the same principle applies when moving from FortiAuthenticator Cloud back to an appliance. Plan time for inventory, recreation and testing.
What does FourTeck need to prepare a UAE quotation?
Provide the user count, current SKU and expiry if applicable, required authentication methods, FortiIdentity Cloud or FortiToken licenses already owned, application and RADIUS integration counts, Fortinet products in use, target date and whether migration or configuration services are required.
Should a new UAE project choose FortiAuthenticator Cloud or FortiIdentity Cloud?
A new project should compare FortiIdentity Cloud first because Fortinet has announced FortiAuthenticator Cloud End of Order. The final choice depends on required features, migration dependencies, user licensing, token methods and project timing. FourTeck can help compare the two paths against the actual environment rather than making a generic recommendation.
Plan the license and migration path before the lifecycle window closes
Whether you are renewing an existing FortiAuthenticator Cloud deployment, adding users, or deciding what should replace it, the next useful step is to share the current user count, expiry date, authentication methods and integration list. FourTeck can help review the technical dependencies, identify the relevant subscription or replacement option, and prepare a UAE quotation with configuration or migration assistance included where required.
Reviews
There are no reviews yet.