Direct answer for buyers
The FortiAuthenticator Hardware Series is a family of physical identity and access management appliances designed to centralise authentication and identity services for network, VPN, administrative and application access. Organisations should consider it when they prefer dedicated on-premises hardware and need services such as RADIUS, TACACS+, MFA, Fortinet Single Sign-On, SAML or OIDC federation, guest workflows or certificate management. Before proceeding, confirm the real local and remote user population, RADIUS and TACACS+ client counts, token quantities, certificate demand, required interfaces, high-availability design, data-centre constraints, software compatibility and expected growth. The appropriate model can change significantly when these factors are measured rather than assumed.
What the hardware series does
FortiAuthenticator acts as a central identity service that can sit between users, directories, network devices and applications. In a typical environment, users may already exist in Microsoft Active Directory, LDAP or another identity source. FortiAuthenticator can use those identities as part of controlled authentication flows while providing services that network equipment and applications understand. This includes RADIUS authentication for VPN, wired and wireless access, TACACS+ for administrator authentication and command authorisation, SAML identity-provider functions, OIDC services, Fortinet Single Sign-On, certificate services and multi-factor authentication.
The appliance does not remove the need for directory governance, role design, network segmentation or change control. Its value is that identity functions can be consolidated into a purpose-built platform so access decisions are easier to manage consistently. That consolidation also makes resilience, backup, time synchronisation, certificate lifecycle, support and recovery more important because a growing number of services may depend on the appliance.
Who should consider it
The hardware range is relevant to organisations that want identity services inside a controlled data-centre, campus or private infrastructure environment. This can include enterprises with FortiGate remote access, campus 802.1X, central network-administrator authentication, application SSO, guest access or internal certificate requirements. A physical appliance can also be attractive where virtual infrastructure ownership is separated from the security team, where a dedicated hardware boundary is preferred, or where predictable rack deployment is part of the organisation’s operating model.
A hardware appliance is not automatically the right choice for every project. A virtual or hosted alternative may be easier where the business avoids data-centre hardware or needs a cloud operating model. The correct comparison should consider lifecycle ownership, resilience, licensing, data location, support processes, virtualisation capacity and integration complexity rather than assuming that physical or virtual deployment is inherently superior.
Business problems the series can help address
Identity projects usually begin with a practical problem rather than a desire to purchase another appliance. Mapping that problem to the required service makes model selection and implementation scope more accurate.
Too many authentication paths
VPN, Wi-Fi, wired access, firewall administration and applications can develop separate authentication logic over time. FortiAuthenticator can provide a common identity layer, but each service should still have explicit policies, test plans and fallback behaviour.
Need for stronger user verification
MFA and passwordless methods can reduce dependence on passwords alone. The chosen factor, token type, enrolment process, lost-device procedure and application compatibility must be planned as part of the project.
Identity-aware network policy
Fortinet Single Sign-On and RADIUS information can help network controls understand who is using an address or session. Accuracy depends on the selected collection method, directory information and network design.
Certificate lifecycle complexity
Certificate services can support VPN, 802.1X and other identity workflows, but issuing certificates creates governance responsibilities around trust, key protection, revocation, renewal and recovery.
Administrative access control
TACACS+ can centralise administrator authentication and command controls for compatible infrastructure. Device support, policy granularity and emergency access must be checked before migration.
Growth beyond an existing RADIUS server
A larger identity estate may need better scale, HA, management and integration than a legacy standalone server provides. Capacity should be based on measured users and network access servers, not only employee headcount.
Choosing between the FortiAuthenticator hardware models
Fortinet’s current series material identifies G-series appliances FAC-300G, FAC-800G and FAC-3000G, while the ordering documentation also lists F-series FAC-300F, FAC-800F and FAC-3000F. The G-series introduces SSD-based local storage across the published family and maintains three broad capacity tiers. Fortinet’s data sheet marks FAC-3000G with an “available Q3 2026” note. Because that statement is a release window rather than a UAE stock commitment, orderability, regional lead time and applicable support SKUs should be confirmed before a quotation is approved.
| Buyer need | Model direction | Main reason | Confirm before ordering |
|---|---|---|---|
| Smaller dedicated IAM deployment | FAC-300G | Base 1,500 users; upper licensed limit 3,500 | User growth, RADIUS clients, no SFP requirement, optional second PSU |
| Mid-sized environment with more identities and access servers | FAC-800G | Base 8,000 users; upper licensed limit 18,000; two SFP interfaces | Token count, certificate volume, optical connectivity, HA and support |
| Large-scale identity environment | FAC-3000G | Base 40,000 users; published upper licensed limit up to one million | Current regional availability, exact interface media, rack/power, client counts and design validation |
The smallest model that technically fits today is not always the lowest-risk choice. If the projected population approaches a model ceiling during the intended support term, if the number of RADIUS clients is unusually high, or if certificate and token use will grow quickly, the next model can provide more operational headroom. Conversely, buying a much larger appliance without a capacity reason can increase cost without improving the identity design. FourTeck can help translate a user and service inventory into a model comparison before commercial approval.
Verified family information for current hardware planning
The table below uses family-level values published in current Fortinet material. It is intended for selection guidance, not as a substitute for the exact quick-start guide, ordering guide, regional bill of materials or software release notes that apply at the time of purchase.
| Field | FAC-300G | FAC-800G | FAC-3000G |
|---|---|---|---|
| Product role | Hardware IAM appliance | Hardware IAM appliance | Large-scale hardware IAM appliance |
| Copper interfaces | 4 × 10/100/1000 RJ45 | 4 × 10/100/1000 RJ45 | 4 × 10/100/1000 RJ45 |
| SFP interfaces | 0 | 2 | 2; confirm exact media/speed for the ordered revision |
| Local storage | 2 × 1 TB SSD, RAID 1 | 2 × 2 TB SSD, RAID 1 | 2 × 2 TB SSD, RAID 1 |
| Local + remote users | 1,500 base / 3,500 upper limit | 8,000 base / 18,000 upper limit | 40,000 base / up to 1,000,000 upper limit |
| FortiTokens | Up to 3,000 | Up to 16,000 | Up to 80,000 |
| RADIUS clients, base / upper | 500 / 1,166 | 2,666 / 6,000 | 13,333 / 80,000 |
| User groups | 300 | 1,600 | 8,000 |
| User certificates | 7,500 | 40,000 | 200,000 |
| Rack format | 1RU | 1RU | 2RU |
| High availability | Active-passive HA and configuration synchronisation are supported on the appliance platform. A complete HA design normally requires a second appliance and validation of all external dependencies. | ||
| UAE availability | Contact FourTeck to confirm current model availability, support entitlement, regional SKU and vendor lead time. | ||
F-series appliances remain listed in current ordering material with similar broad capacity tiers but different storage and hardware details. Buyers comparing an existing FAC-300F, FAC-800F or FAC-3000F deployment with a new purchase should confirm lifecycle, support entitlement, migration path, replacement generation and the exact bill of materials rather than assuming that an F-series and G-series appliance are interchangeable. In particular, the FAC-3000F has a published upper user limit of 240,000, while FAC-3000G is documented for a substantially higher licensed upper limit. That difference can matter for long-term scaling, but only when the organisation’s real identity and client counts justify it.
Licensing, tokens and configuration dependencies
A base hardware appliance is only one part of a complete identity project. Fortinet’s hardware user-upgrade licences are stackable within the documented model limits, so capacity can be increased without replacing the appliance when the required growth remains inside that ceiling. FAC-HW-100UG and FAC-HW-1000UG are used across applicable hardware models, while larger increments are available for higher-capacity tiers. The quotation should show the base model, user-upgrade quantity and resulting licensed user capacity clearly enough that procurement can understand what is being purchased.
FortiToken Mobile and physical FortiToken products are separate commercial items. FIDO hardware tokens are also separate. SMS-based authentication may require a FortiGuard SMS entitlement or a supported third-party SMS gateway. Email one-time passwords can rely on the organisation’s mail path. These methods differ in user experience, cost, assurance, offline behaviour and support workload. A project should therefore choose authentication methods service by service instead of assuming every user needs the same factor.
The FortiClient SSO Mobility Agent also has separate licensing in the ordering guide. When the project depends on endpoint-derived identity or transparent user tracking, the applicable agent licence and FortiClient design should be included in the bill of materials. Likewise, advanced or carrier functions are not automatically standard across all models; applicability should be checked against the exact appliance and use case.
Support should be treated as an explicit line item with the correct term and service level. Registration, firmware access, support entitlement, replacement expectations and renewal ownership need to be agreed before the appliance becomes a production dependency. FourTeck can help clarify these commercial dependencies, but the final quotation should name exact SKUs rather than use a generic statement such as “all licences included.”
A practical purchase and deployment journey
Inventory identity services
List VPNs, Wi-Fi, wired 802.1X, network administration, applications, guest access, directories, tokens and certificate services. Count what will actually use FortiAuthenticator, including contractors, remote users, service identities and branch devices where relevant.
Size the appliance
Compare current and three-to-five-year user counts with RADIUS clients, certificates, FortiTokens, groups and interface requirements. Leave sensible operating headroom instead of designing directly against the upper limit.
Build the bill of materials
Specify the exact appliance, user upgrades, FortiTokens, SSO agent licensing, SMS entitlement where needed, support term, redundant power option, second appliance for HA and any professional services.
Design integrations
Document Active Directory or LDAP, RADIUS clients, SAML service providers, OIDC applications, FortiGate integration, DNS, NTP, mail, SMS, certificate trust and management networks. Record firewall rules and ownership for each dependency.
Pilot before migration
Test with representative users and devices. Include failed passwords, expired tokens, locked accounts, unreachable directories, certificate errors and authentication timeouts. A successful login is only one part of acceptance testing.
Cut over in controlled waves
Move services in an order that limits business risk. Keep rollback paths for remote access and administrator authentication, and coordinate user communications when MFA enrolment or passwordless methods change behaviour.
Operationalise the platform
Schedule backups, review certificate expiry, record support dates, control administrative roles, monitor logs and document recovery. Identity infrastructure needs routine ownership after the project team has finished deployment.
Review growth before renewal
Compare actual users, clients and service adoption with the original assumptions. This is the right time to add licences, change support terms or plan a larger appliance rather than waiting until a limit becomes an operational problem.
Central authentication without losing policy clarity
RADIUS and TACACS+ are often the first reasons organisations evaluate FortiAuthenticator hardware. RADIUS can support authentication, authorisation and accounting for VPN, wired and wireless access, while TACACS+ can be used for administrative authentication and command controls on compatible infrastructure. Centralisation reduces the number of places where access rules are duplicated, but it also creates a need for clean policy ownership. Each RADIUS client should have a documented purpose, secure shared secret, permitted source address, timeout behaviour and expected attributes. TACACS+ policies should distinguish routine operator tasks from higher-risk administrative commands where the device and design support that granularity.
For 802.1X, the surrounding access network matters as much as the authentication server. Switches, wireless controllers, supplicants, certificates, EAP method, VLAN assignment, endpoint onboarding and failure handling all have to work together. FortiAuthenticator supports certificate-based EAP-TLS as part of this architecture, but certificates need an enrolment and renewal process. A technically correct RADIUS response does not by itself guarantee that the endpoint receives the intended network access.
The hardware model becomes relevant when the number of network access servers grows. A multi-site organisation may have many FortiGate appliances, switches, wireless controllers and other RADIUS clients even when the employee count is moderate. Counting these devices during sizing can prevent the organisation from selecting a user-capacity tier that appears adequate but is constrained by client limits later.
MFA, adaptive authentication and passwordless choices
FortiAuthenticator supports several ways to strengthen authentication beyond a password. FortiToken Mobile can provide one-time passwords and supported push experiences, physical FortiToken devices can serve users who cannot rely on a personal smartphone, and FIDO2 can support passwordless authentication workflows where the service and policy design allow it. SMS and email one-time passwords may also be used in suitable scenarios. These choices should be evaluated for both assurance and operational reality: a method that is secure but impossible for a group of users to enrol or recover will create support pressure and workarounds.
Adaptive authentication can apply context to the decision process. Location, device context, time and other login conditions can influence whether access is granted, challenged or blocked according to configured policy and supported integrations. The objective should be a clear risk rule rather than complexity for its own sake. Buyers should identify which applications or user populations genuinely need contextual controls and how exceptions will be reviewed.
Token quantity should not be confused with appliance user capacity. A company may have 8,000 identities but only a subset requiring a particular token method, or it may require additional test, spare or contractor tokens. Conversely, a shared account model should not be used simply to reduce licensing because it can weaken accountability. The authentication design should define named identities, enrolment, recovery, token replacement, administrators, temporary access and user offboarding before commercial quantities are finalised.
SSO, federation and certificate services in a wider identity architecture
FortiAuthenticator can operate as a SAML Identity Provider and IdP proxy, and it supports OAuth and OpenID Connect services for applicable application flows. SCIM provisioning can help automate identity information exchange between systems that support it. These capabilities can reduce the need for every application to maintain a separate authentication approach, but federation projects depend on accurate metadata, signing certificates, claims, group mapping, redirect URLs and application-specific behaviour. A successful connection to one service does not prove that another application will behave the same way.
Fortinet Single Sign-On provides another identity path by collecting or receiving user-to-IP information that can be shared with FortiGate for identity-based policy. The collection approach may involve directory polling, accounting information, agents or other supported mechanisms. The right method depends on how users log in, how often IP addresses change, whether terminal servers or shared devices are involved, and how branches connect. Identity should be verified against the actual network behaviour rather than inferred from a diagram alone.
Certificate management can support server and user certificates, SCEP, VPN use cases and certificate-based network access. This can be valuable for organisations that want stronger machine or user identity, but a certificate authority is a trust service, not simply another feature to switch on. Naming standards, key protection, certificate validity, revocation, recovery, approval workflows, backup and expiry monitoring should be documented. If the organisation already operates an enterprise PKI, the architecture should define which system remains authoritative and where FortiAuthenticator adds value.
Where the hardware family can fit well
Enterprise headquarters and branches
A central appliance can provide VPN MFA, network access authentication and administrator identity for multiple sites. WAN failure behaviour and branch emergency access should be tested before centralisation becomes mandatory.
Education and campus networks
Students, staff, contractors, guests and managed devices can create diverse authentication requirements. User turnover, 802.1X, certificate onboarding, sponsor workflows and seasonal peaks should be considered in sizing.
Healthcare and professional services
MFA, administrative controls and certificate-based access can support an organisation’s security programme. FortiAuthenticator contributes technical controls, while governance, access review and regulatory obligations remain organisational responsibilities.
Hospitality and distributed operations
Guest access, workforce authentication and multiple sites can benefit from central identity services. The design must distinguish guest, employee, contractor and administrator workflows and account for unreliable WAN paths where applicable.
Industrial and restricted networks
A physical appliance may suit controlled environments that minimise dependency on shared virtual infrastructure. Offline operation, safe change windows, NTP, token activation, backup and local recovery require special attention.
Service-provider or very large identity estates
Higher-capacity models can support much larger user and RADIUS-client populations. Advanced carrier licensing, high availability, operational separation and exact capacity assumptions should be validated before purchase.
Integration and operational considerations that affect success
Identity infrastructure touches systems owned by different teams. Directory administrators control accounts and groups; network teams own switches, wireless systems and firewalls; application teams manage federation metadata; endpoint teams control client configuration; and security teams may own MFA, certificates and policy. A FortiAuthenticator deployment should name these owners early. Many failed authentication projects are not caused by the appliance itself but by an expired certificate, changed group, blocked network path, DNS issue, time drift or application configuration that falls outside the identity team’s direct control.
DNS and NTP deserve explicit design attention. Federation, certificate validation, directory connectivity and event correlation can all behave unpredictably when names do not resolve consistently or system clocks diverge. Management interfaces should sit on approved networks, administrative access should be restricted, and configuration backups should be stored securely. Because identity configuration may contain sensitive directory details and certificate material, backup handling needs the same governance as other security infrastructure.
High availability reduces appliance failure risk but does not protect every dependency. Two FortiAuthenticator nodes can still be affected by an unreachable directory, WAN outage, DNS failure, expired SAML certificate or common power event. A resilience test should therefore include service dependencies, not only appliance failover. For business-critical remote access, organisations should decide how administrators regain access when the preferred identity path is unavailable, and any emergency method should be controlled, logged and periodically tested.
Software version compatibility should also be reviewed before upgrade. FortiAuthenticator evolves with new authentication and federation capabilities, while FortiGate, FortiClient, browsers, directory platforms and applications change independently. Production upgrades should follow supported paths, use current release documentation and include validation of the integrations that matter to the organisation.
Questions to resolve before asking for a quote
A model recommendation becomes much more reliable when the quotation request answers the following questions. They help separate appliance capacity from licensing, integration and implementation scope.
- How many local and remote identities will use FortiAuthenticator today, and what is the expected count at the end of the support term?
- How many FortiGates, switches, wireless controllers, VPN devices and other RADIUS clients will connect?
- Is TACACS+ required for administrator authentication or command authorisation?
- Which MFA methods are required, and how many FortiToken Mobile, hardware or FIDO users are expected?
- Which directories, SAML applications, OIDC applications or SCIM integrations are in scope?
- Will FortiAuthenticator operate certificate services, and what certificate volume and lifecycle are expected?
- Is active-passive HA required, and are separate power, switch and rack paths available?
- Are copper interfaces sufficient, or does the data-centre design require SFP connectivity?
- What FortiCare term and support level should be included?
- Does the project require installation, migration, policy configuration, testing, documentation or training?
Procurement checklist for FortiAuthenticator hardware
The checklist should become part of the commercial record. If the quotation contains only an appliance SKU while the project depends on user upgrades, tokens, support, a second node and implementation work, procurement cannot compare offers accurately. A clear bill of materials also makes future renewals and expansions easier because the organisation knows which capacity and entitlement assumptions were used at purchase.
How FourTeck can assist with model selection and project scope
FourTeck can review the identity requirement before a model is selected. That review can cover user counts, FortiGate and third-party RADIUS clients, MFA methods, FortiToken quantity, high availability, directory sources, certificate use, federation applications, support term and data-centre constraints. The goal is to produce a bill of materials that reflects the intended service instead of quoting a hardware box in isolation.
Where deployment assistance is required, the scope can separately identify installation, base configuration, directory integration, RADIUS or TACACS+ onboarding, FortiGate integration, MFA enrolment planning, SSO configuration, certificate work, migration, testing, documentation and handover. Not every activity is automatically included with product supply, so buyers should request a written scope that states prerequisites, exclusions and responsibilities.
For broader project support, review FourTeck technology services, explore the Fortinet UAE product portfolio, or discuss a FortiGate integration requirement through the Fortinet firewall solutions page. Compatibility, exact scope and current commercial terms should always be confirmed for the specific project.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for the exact FortiAuthenticator appliance, quantity, user-upgrade licences, FortiTokens, power options and support term. Availability can vary by model generation, regional SKU, quantity, channel position and vendor lead time. A product listed in current documentation is not the same as a guarantee of immediate UAE stock, and an online price from another market may not include the support, tax, freight or regional commercial conditions that apply locally.
For projects in Dubai, Abu Dhabi, Sharjah and Ajman, FourTeck can coordinate requirement review, quotation preparation, delivery planning and optional implementation discussions once the exact scope is known. Delivery and project coordination should identify the receiving site, rack readiness, power, cabling, access restrictions and responsible contact. Installation and configuration should be included in the quotation when required rather than assumed to be part of hardware supply.
GCC Availability
Organisations planning FortiAuthenticator hardware deployments across the GCC can ask FourTeck to review the destination, model capacity, user licensing, token requirements, high-availability design, support term and implementation scope before commercial coordination begins. Projects in the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman may have different regional SKU, delivery, licensing, service-visit and vendor lead-time considerations. For a useful regional quotation, provide the destination country, exact appliance or capacity target, quantity, expected local and remote users, FortiToken requirements, support duration, deployment location and required timeline. Multi-country projects should also define whether identity services will be centralised or deployed per country, because WAN resilience and data-governance requirements can alter the architecture. FourTeck can assist with requirement review and quotation planning, but product availability, delivery schedules, installation scope and support arrangements remain subject to confirmation for each destination and project.
Africa Availability
For African deployments, the correct FortiAuthenticator choice depends on more than user count. Destination country, model generation, power and rack conditions, support entitlement, token requirements, shipping arrangements, regional licensing, installation scope and local project constraints can influence the final bill of materials. FourTeck can help organisations in East Africa and other regions evaluate appliance size, FortiTokens, user upgrades, high availability, integration needs, renewal planning and deployment responsibilities. Buyers should share the exact destination, current and projected user population, required quantity, directory and application integrations, preferred deployment schedule and any on-site or remote support expectations. Availability and fulfilment can vary by destination and vendor lead time, so a UAE quotation should not be treated as a confirmed African delivery commitment. For regional technology enquiries, organisations can also review FourTeck Africa solutions and submit the specific requirement for commercial confirmation.
Related options to consider with the hardware series
FortiToken options
Mobile, physical and FIDO authentication methods can be evaluated according to user experience, assurance level, offline needs and replacement process. Token products are not automatically included with the base hardware appliance.
FortiAuthenticator VM or cloud delivery
A virtual or hosted identity platform can be compared when rack hardware is undesirable or the organisation has a strong cloud operating model. Licensing and resilience differ from hardware, so compare equivalent requirements.
FortiGate identity integration
FortiAuthenticator can support FortiGate remote access, administrator authentication and identity-aware policies. The FortiGate design, FortiOS compatibility and specific authentication flow should be verified.
Deployment and migration services
Professional services can cover discovery, configuration, migration, testing, documentation and handover when the customer does not want to perform the entire identity transition internally.
Why businesses contact FourTeck for FortiAuthenticator projects
The useful part of a supplier conversation is requirement clarification. A buyer may know that MFA is needed but not how many RADIUS clients exist, or may know the employee count without knowing how many accounts, certificates and service integrations will consume the identity platform. FourTeck can help organise those inputs into a model and bill-of-material discussion so procurement receives a clearer commercial request.
Assistance can include model comparison, licence clarification, FortiToken planning, compatibility questions, high-availability scoping, support-term selection, quotation coordination, migration planning and implementation scope. These activities do not replace customer governance or vendor documentation; they help connect the technical requirement to an order that can be reviewed and approved. For company information, visit About FourTeck.
What buyers usually need to know before shortlisting a hardware model
A common buying question is whether the model number can be selected from employee count alone. It cannot. Employee count is a useful starting point, but FortiAuthenticator capacity planning is broader because local and remote identities, RADIUS clients, user groups, FortiTokens and certificates have separate published limits. An organisation with 1,200 employees and hundreds of branch devices can have a very different requirement from another organisation with the same number of employees and only two VPN gateways. The first practical step is therefore to create an identity-service inventory: who authenticates, what authenticates them, which devices ask the question, and which business services fail if authentication is unavailable.
Is FAC-300G enough for a growing company?
It can be a strong fit when the required user population remains inside its 1,500-user base capacity and documented 3,500-user upper limit, and when its RADIUS-client, certificate, token and interface limits also fit. A company expecting rapid growth toward 3,500 users should compare FAC-800G before purchase rather than planning an early platform replacement.
When does FAC-800G become the more sensible tier?
FAC-800G is the natural comparison when user capacity, RADIUS clients, token volume, certificate volume or optical connectivity exceed the smaller appliance’s practical fit. Its base licence supports 8,000 users and can be expanded to the documented 18,000-user upper limit, providing a different growth envelope.
Buyers also ask whether FortiAuthenticator is only useful in a Fortinet environment. It has particularly strong value in Fortinet deployments because it integrates with FortiGate and the wider Fortinet identity workflows, but it also supports standard technologies such as RADIUS, LDAP, SAML, OAuth/OIDC and TACACS+ that are used by many third-party platforms. Compatibility should still be tested at the exact application or device level. Saying that two systems both “support RADIUS” is not enough to prove that all attributes, accounting behaviour, dynamic VLAN functions or administrative policies will work exactly as required.
Another frequent question concerns MFA licensing. The appliance provides the platform capability, but FortiToken Mobile licences, physical FortiTokens and FIDO hardware tokens are separate commercial items. SMS may also require a FortiGuard SMS licence or compatible third-party gateway. This distinction matters when comparing quotations because an appliance-only price can look attractive while omitting the authentication factors required by the project. Procurement should ask suppliers to show the number and type of tokens, support term and any user-upgrade licences as explicit lines.
High availability is not just “buy two appliances.” The design should confirm node placement, switch paths, power sources, management access, synchronisation, virtual IP or service behaviour where applicable, directory reachability and failover testing. If both nodes depend on one WAN circuit or one directory server, the architecture still contains a common failure point.
Price questions are also common, but a family page cannot provide a reliable single selling price because the selected model may be FAC-300G, FAC-800G, FAC-3000G or another currently orderable generation, and the final package may include licences, FortiTokens, FortiCare, redundant power, a second HA node and implementation services. Online prices from other markets can help a buyer understand that these are enterprise appliances, but they should not be treated as a UAE quotation. Currency, tax, freight, support registration, bundles and channel conditions can change the commercial result.
Existing F-series customers often want to know whether they must migrate immediately to G-series. A generation change alone does not answer that question. The current appliance’s support status, software requirements, capacity headroom, storage health, certificate services, HA design and business lifecycle should be reviewed. If an F-series model remains supported for the organisation’s required software and has sufficient capacity, migration can be planned deliberately. If support, capacity or hardware risk is driving the project, a G-series comparison becomes more urgent. FourTeck can review the existing model and target requirement without assuming a one-for-one replacement.
Finally, buyers should prepare for implementation before the hardware arrives. Directory service accounts, DNS, NTP, firewall rules, certificates, RADIUS shared secrets, SAML metadata, test users, FortiToken enrolment, change windows and rollback plans can take longer to organise than rack installation. A well-prepared project treats the appliance as one component in an identity service and schedules technical ownership across network, security, directory and application teams. That preparation reduces the risk of discovering an external dependency during the production cutover.
Questions that change the appliance decision
Do we count every directory account as a licensed user?
Not necessarily in the same operational sense. The requirement should identify which local and remote users will actually consume FortiAuthenticator services, how synced or remote identities are used and how guest or temporary accounts fit. Confirm the licensing interpretation for the intended design before ordering rather than applying the total directory count automatically.
Can one appliance support VPN, Wi-Fi and admin logins together?
Yes, the platform can serve multiple authentication use cases, but the combined user, client and operational load must fit the chosen model. More importantly, each service needs separate policies and testing. A change made for VPN authentication should not unexpectedly affect administrator access or campus 802.1X.
What if the business wants passwordless access later?
Plan the identity architecture with future authentication methods in mind. FortiAuthenticator supports FIDO-based passwordless workflows, but application compatibility, user devices, hardware tokens, enrolment and recovery processes still determine whether a specific service can move away from passwords.
Does RAID mean backups are optional?
No. RAID protects against certain drive failures; it does not protect against configuration mistakes, corruption, deleted objects, certificate problems or site loss. Secure configuration backups, documented restore procedures and tested recovery remain necessary.
How much growth headroom should we leave?
There is no universal percentage because growth can occur in users, RADIUS clients, certificates and tokens at different rates. Compare realistic three-to-five-year demand with every relevant model limit. If one important metric is likely to approach the ceiling during the support term, evaluate the next tier.
What information makes a quotation accurate?
Provide the exact deployment country, user count, RADIUS and TACACS+ client count, token types and quantities, directory sources, federation applications, certificate requirements, HA preference, support term, rack and interface needs, migration scope and target timeline. That information turns an appliance price request into a usable project quotation.
FortiAuthenticator Hardware Series FAQs
Which FortiAuthenticator hardware models are in the current G-series?
Current Fortinet series material identifies FAC-300G, FAC-800G and FAC-3000G. The same ordering material also lists F-series models. Confirm the currently orderable generation, support entitlement and UAE availability before purchase because documentation presence does not guarantee local stock.
How many users can the G-series appliances support?
FAC-300G is documented for 1,500 users in the base licence and up to 3,500 with hardware user upgrades. FAC-800G starts at 8,000 and can expand to 18,000. FAC-3000G starts at 40,000 and has a published upper licensed limit of up to one million users. Other capacity limits should be checked at the same time.
Are FortiTokens included with a FortiAuthenticator hardware appliance?
FortiToken Mobile licences, physical FortiTokens and FIDO hardware tokens are separate commercial items. The quotation should specify token type, quantity and any related service or activation requirements. SMS authentication may also require a FortiGuard SMS entitlement or a supported third-party gateway.
Can FortiAuthenticator work with third-party network devices and applications?
Yes, FortiAuthenticator supports standard identity and authentication protocols including RADIUS, LDAP, SAML, OAuth/OIDC and TACACS+. Actual compatibility depends on the exact third-party product, software version, attributes and desired workflow, so integration should be validated before production use.
Does the hardware series support high availability?
The appliance platform supports active-passive high availability and configuration synchronisation. A production HA design normally requires a second compatible appliance plus resilient power, network paths and external identity dependencies. Failover should be tested for each important authentication service.
When should FAC-800G be considered instead of FAC-300G?
FAC-800G should be evaluated when user growth, RADIUS clients, token volume, certificate demand or optical-interface requirements exceed the practical fit of FAC-300G. The decision should compare all relevant published limits and expected growth rather than relying only on current employee count.
Can FortiAuthenticator replace Microsoft Active Directory?
FortiAuthenticator is normally used with directory services rather than as a wholesale replacement for Active Directory. It can authenticate against remote identity sources and add RADIUS, SSO, MFA, certificate and federation services. The authoritative user directory and password ownership should be defined in the architecture.
Is installation included with the hardware purchase?
Installation, configuration, migration, integration, testing, documentation and training should be treated as defined professional-service items unless the quotation explicitly includes them. Identity projects vary significantly, so the service scope should state prerequisites, customer responsibilities and acceptance criteria.
How can I confirm current FortiAuthenticator pricing and availability in Dubai?
Send FourTeck the preferred model or capacity requirement, quantity, user licences, FortiToken needs, FortiCare term, HA requirement and deployment scope. FourTeck can then confirm current UAE commercial options and lead time. Online prices from other countries should not be treated as a final Dubai quotation.
Confirm the right FortiAuthenticator hardware tier before ordering
A useful FortiAuthenticator quotation should match identity scale, network access servers, token requirements, certificate use, interfaces, high availability and support to the real project. Share your current user count, growth plan, sites, authentication services and preferred timeline with FourTeck. The team can help compare the applicable hardware models, clarify licence dependencies and prepare a requirement-based UAE quotation.