A FortiAuthenticator deployment can either reduce identity risk across the business or create a new point of failure that frustrates users and service desk staff. The difference is preparation. This FortiAuthenticator deployment checklist is designed for Australian IT and security teams that need to introduce centralised authentication and MFA without compromising operational continuity.
FortiAuthenticator is most effective when it is treated as a core identity service rather than simply an MFA appliance. It can support FortiToken-based MFA, RADIUS authentication, SAML single sign-on, certificate services and identity synchronisation. The right design depends on which of those services are in scope, which systems must remain available, and how much internal capability is available to support them.
Start with the required security outcome
Before choosing policies, tokens or integration methods, define what the deployment must achieve. A small business may need MFA for remote VPN access and administrator accounts. A multi-site organisation may need central authentication for FortiGate, wireless, switches, cloud applications and privileged systems. A regulated environment may also need auditable identity controls, clear separation of duties and a documented recovery process.
Write down the systems in scope, the user groups affected and the authentication methods each system currently uses. This exposes hidden dependencies early. For example, an ageing line-of-business application may rely on LDAP, while remote access uses RADIUS and a SaaS application requires SAML. FortiAuthenticator can support these requirements, but the deployment sequence and testing approach should reflect them.
Agree measurable acceptance criteria with security, infrastructure and business stakeholders. Useful criteria include successful MFA enrolment rates, authentication response times, audit log retention, a tested administrator lockout process and the ability to restore the service within an agreed recovery window.
FortiAuthenticator deployment checklist: design first
A sound deployment begins with design decisions that are difficult to change once users depend on the service. Complete the following checks before production configuration begins:
- Confirm the FortiAuthenticator model, virtual appliance sizing or cloud design suits current users, expected transaction volumes and growth.
- Confirm the required FortiToken licensing, including allocation for administrators, remote workers, contractors and replacement tokens.
- Define authoritative identity sources, such as Microsoft Active Directory, LDAP directories or cloud identity platforms.
- Document every RADIUS client, SAML service provider, VPN, firewall, wireless network and administrative portal to be integrated.
- Allocate a static management address, production DNS name, network routes and firewall rules for all identity and authentication traffic.
- Select the certificate authority and certificate lifecycle process for HTTPS, SAML signing and any certificate-based authentication.
- Define high availability, backup, restore and disaster recovery requirements before relying on the platform for critical access.
Size for service continuity, not just user count
Sizing should consider more than the number of named users. Authentication demand often arrives in spikes. A remote workforce may authenticate at the start of the day, after a network interruption or during a VPN reconnection event. Large site failovers can also create a sudden concentration of requests.
Virtual deployment can provide flexibility where an organisation has mature virtual infrastructure and recovery processes. A dedicated appliance can offer a more contained operational model. Neither option is universally better. The practical choice depends on existing platform standards, resilience requirements, internal skills and the cost of an authentication outage.
For critical environments, determine whether high availability is required and test what happens when a node, network path or identity source fails. Redundancy that has not been tested is an assumption, not resilience.
Prepare identity data and access policy
Authentication quality depends on identity quality. Review directories before synchronisation. Remove dormant accounts where appropriate, confirm group ownership and identify shared or generic accounts that should not receive ordinary MFA treatment. Shared administrative accounts make accountability difficult and should be replaced with named access wherever possible.
Create groups around access decisions rather than organisational charts. For example, separate VPN users, network administrators, finance application users, contractors and service accounts. This makes it easier to apply an appropriate method to each group and reduces the chance of forcing MFA onto a non-interactive service account that cannot complete it.
Define exceptions carefully. Break-glass accounts may be necessary for emergency recovery, but they should be tightly controlled, monitored and stored under a documented process. An exception should not become an unmanaged route around MFA.
Choose authentication methods by risk and user context
FortiToken Mobile is often a practical fit for staff with managed mobiles and remote access needs. Hardware tokens may suit users without corporate mobiles, staff in restricted environments or organisations that need a physical factor. Email or SMS-based approaches may appear convenient, but their suitability depends on risk tolerance, mobile coverage, delivery reliability and policy requirements.
Do not apply one method blindly to every user. Privileged administrators, contractors, frontline staff and third parties have different working conditions. A well-designed policy improves adoption because it matches security controls to the way people actually access systems.
Build the technical foundations carefully
Time, name resolution and certificates are routine infrastructure services until they fail. FortiAuthenticator, directory services, FortiGate devices and applications need reliable NTP. A meaningful time difference can cause certificate and token validation issues that resemble user errors. Use approved time sources, confirm synchronisation and ensure event timestamps are consistent for investigations.
DNS must resolve the production service name correctly from every relevant network. If SAML is in scope, ensure the externally presented URL, certificate subject names and application metadata align precisely. Certificate mismatches are among the most avoidable causes of failed federation deployments.
Limit administrative access to approved management networks and named administrator accounts. Use least privilege for FortiAuthenticator administrators, apply MFA to administration where feasible, and forward logs to the organisation's monitoring or SIEM platform. Authentication logs are valuable evidence when investigating access attempts, account misuse and configuration changes.
When integrating RADIUS clients, use distinct shared secrets, record the source addresses and restrict network paths so only approved devices can submit requests. For LDAP connectivity, use secure protocols and a service account with only the permissions required to read the selected users and groups.
Pilot one service before broad rollout
The first production integration should be important enough to prove the design but contained enough to recover quickly. VPN access for an internal pilot group is often a sensible starting point. It tests identity synchronisation, RADIUS, token enrolment, support processes and user communications without immediately affecting every business application.
Include a representative pilot group: IT administrators, standard office users, remote workers and at least one user who relies on a mobile-only workflow. Their feedback will reveal practical issues that architecture diagrams do not show, such as a confusing enrolment email, poor mobile coverage at a site or a forgotten shared device process.
Test normal and failure conditions. Validate successful sign-in, invalid token handling, lost-token replacement, user lockout, password reset interactions, directory unavailability, certificate expiry alerts and restoration from backup. Document expected behaviour and assign ownership for each response. This is where a deployment becomes an operational service.
Plan user enrolment and support capacity
MFA projects are often judged by the first week of user experience, not by the quality of the design documentation. Communicate why the change is occurring, what users need to do, when it will happen and where they can get help. Keep instructions short and use the exact terminology users will see during enrolment.
Stage enrolment by department, site or application risk. A phased rollout gives the service desk time to identify patterns and adjust communications. It is usually safer than enabling enforcement for every user on the same morning, particularly where staff work shifts or have limited access to email and corporate mobiles.
Prepare clear procedures for token activation, replacement, device changes and emergency access. Confirm who can perform each action and what identity verification is required. A quick workaround without verification may solve a short-term ticket while creating a material security gap.
Put ownership, monitoring and recovery into operations
After go-live, review authentication failures, token inventory, inactive accounts, administrator activity and integration health at a planned interval. Monitor certificate expiry, directory synchronisation status, disk capacity, system alerts and backup completion. These controls are less visible than MFA prompts, but they are what keep the service dependable over time.
Maintain a change record for new applications, RADIUS clients, SAML integrations and policy exceptions. Each new dependency should be assessed for authentication flow, fail-open or fail-closed behaviour, certificate requirements and rollback options. In some cases, fail-closed is the right security choice; in others, an outage may stop essential operations. That decision should be made explicitly by the business and security owner, not during an incident.
FortiSecure Store can assist organisations that need the right FortiAuthenticator licensing, a validated architecture or certified deployment support alongside their Fortinet security investment. The strongest outcome is not simply MFA switched on. It is a well-owned identity service that users can rely on and your security team can defend.