Remote access is a business service with several dependencies. The user needs a suitable endpoint, a supported connection method, a working identity process and permission to reach the applications required for the job. A successful connection indicator confirms only part of that service.
For organisations planning FortiClient remote access, the first decision is the supported architecture for the actual product releases. Copying an older deployment guide can introduce assumptions that no longer apply. The plan must account for FortiOS, FortiClient, endpoint operating systems and any management or identity components involved.
The business design matters just as much. An employee completing payroll, a contractor maintaining one server and a manager checking an internal dashboard do not necessarily need the same access. Establish those differences before choosing settings or distributing a client package.
Resolve the FortiOS release question first
Fortinet’s FortiOS 7.6.3 release notes state that SSL VPN tunnel mode is replaced by IPsec VPN, is unavailable in the GUI and CLI, and its settings are not carried forward from earlier versions. The notice applies to all FortiGate models. It calls for migration before upgrading to 7.6.3.
That specific change means an older SSL VPN tunnel design cannot simply be assumed to survive a move to that release. Treat the gateway upgrade and remote-access migration as connected work. Confirm the requirements of the actual target release and the supported FortiClient version before approving either change.
This does not make every older deployment identical or establish a universal configuration recipe. Other release and model constraints may matter, and the endpoint environment still needs checking. Ask the implementation team to document the exact supported combination and the official guidance used for the proposed design.
Avoid selecting a target solely because its version number is higher. The decision should consider the organisation’s requirements, applicable release notes, compatibility and support position. Record the chosen architecture so future administrators can see why the remote-access service was built that way.
Describe access in terms of work
Build a role-to-application map. For each role, identify the business tasks, application destinations, required working hours and responsible application owner. Include supporting services such as name resolution or authentication where they are necessary to complete the task.
Separate employee access from third-party access. A supplier’s maintenance requirement may be temporary and narrowly defined, while an employee may need a recurring set of business applications. Shared treatment can make permissions difficult to explain and access difficult to remove when a contract ends.
Consider whether every requested application needs network-level remote access. The organisation may already provide some work through approved external services. The purpose of the assessment is to understand the requirement, not to force every activity through the same connection method.
Write acceptance statements that users can recognise. “The finance analyst can open the approved accounting application and submit the authorised transaction” is more useful than “VPN connects.” Also state what the role should not reach, such as unrelated server administration interfaces.
Define who may use which devices
Classify endpoints by ownership and management responsibility. A company-managed laptop can follow a different support and maintenance process from a personal computer. The organisation should decide which categories are eligible before onboarding users.
For each approved category, check the operating system, FortiClient release, installation method and relevant compatibility guidance. Do not assume that a configuration validated on one operating system behaves identically on another. Features, supported combinations and licensing should be confirmed for the exact proposed deployment.
Document endpoint prerequisites in language users can follow. They should know how software is installed, how updates are delivered, who handles faults and what happens if the device no longer meets the organisation’s requirements. Avoid relying on informal instructions passed between colleagues.
Include replacement and repair scenarios. A user whose laptop fails should have an approved route back to work without copying credentials or configuration through an unmanaged channel. The recovery process for the endpoint is part of the remote-access service, not an exception to it.
Design identity controls around the whole lifecycle
Identify the authoritative source for user accounts and group membership. The remote-access design should explain how a new employee receives access, how a role change alters permissions and how departure removes access. If several teams participate, name the handoff between them.
Require the implementation team to verify the supported authentication and multifactor options for the selected architecture. The organisation should decide the intended assurance level and recovery policy; the technical design must then show how those requirements are implemented in the chosen versions.
Account recovery deserves particular attention. A lost phone, expired credential or unavailable identity service can block legitimate work. Define who can approve recovery, how the requester is verified and how temporary arrangements expire. A weak recovery process can undermine an otherwise carefully designed sign-in experience.
Test removal as well as enrolment. It should be possible to demonstrate that a user who is no longer authorised cannot start the prohibited work through the approved access route. Assess existing sessions and related application permissions according to the deployed architecture rather than assuming one account change resolves every layer instantly.
Decide how remote traffic should be handled
The traffic design should reflect application and security requirements. Discuss which destinations must use the remote-access path, how name resolution is handled and what the user experience should be when the connection is unavailable. Have the network team explain the consequences of the selected routing approach.
Consider users working from home networks, mobile connections and guest networks. Addressing conflicts, variable connectivity and local restrictions can affect results. Include representative environments in testing without assuming that one successful office-based test proves remote usability.
Document how users distinguish a connection problem from an application problem. A short support guide can ask them to record the time, application, network type and visible error without requesting passwords or sensitive data. This gives the service desk a useful starting point.
Maxicon’s IT services provide a relevant route for discussing remote-access requirements together with endpoint support and identity ownership. A coordinated assessment helps avoid designing a connection that the support team cannot maintain.
Pilot the service with representative workflows
Select pilot participants by the work they perform and the environments they use. Include different approved endpoint types, important applications and realistic remote networks. Volunteers who all use the same laptop and application may leave significant assumptions untested.
Prepare a test record before the pilot begins. Each test should identify the user role, endpoint version, connection method, application activity and expected outcome. Record failures with enough context to reproduce them, while keeping credentials and unnecessary personal information out of the record.
Exercise sign-in, reconnection and ordinary work. Include a fresh application session, a longer task and an interruption where it is safe to do so. A connection that works briefly may still produce a poor experience during the actual activity the user needs to complete.
Test denied access deliberately using approved accounts and targets. Confirm that a contractor role cannot reach unrelated resources and that a removed pilot user is treated as intended. Security acceptance should be based on the agreed access boundary as well as convenience.
Treat migration as a service transition
Where an existing remote-access method must change, inventory the active users and client configurations first. Identify people who connect infrequently; they may miss routine communications and discover the change only when travelling or working outside office hours.
Plan the order of endpoint preparation, identity changes, gateway changes and user communication. The sequence should be supported by the selected architecture and tested before broad rollout. Do not assume that a gateway upgrade can be separated from client readiness when the release changes the available connection method.
Provide clear cutover instructions with a support route. Users need to know when to change, what visible behaviour to expect and how to report a problem. Avoid including implementation detail that does not help them complete the transition.
Define recovery in advance. Specify what can be restored, what prerequisites are required and who can authorise the decision. A previous client package alone may not recover the service if the gateway architecture has changed. Validate the complete route with the engineering team.
Operate remote access after launch
Keep an inventory of the approved combinations and assign responsibility for reviewing release changes. Endpoint updates, identity changes and gateway maintenance can all affect the service. Connect those change processes so the remote-access dependency is considered before implementation.
Review access ownership periodically. Temporary accounts should have an end date, unusual permissions should have an explanation and inactive access should be investigated with the business owner. Avoid using activity alone as the sole criterion because some legitimate roles connect infrequently.
Use support trends to improve the service. Repeated enrolment failures may indicate unclear instructions; recurring problems on one endpoint category may require a compatibility review. Distinguish these operational findings from confirmed security incidents and route them appropriately.
To discuss a FortiClient remote-access plan, contact Maxicon with your gateway release, endpoint categories, application requirements and identity arrangement. These details allow the conversation to focus on a supported, maintainable service rather than a generic connection setup.
Frequently asked questions
Can we keep using SSL VPN tunnel mode after upgrading to FortiOS 7.6.3?
Fortinet’s release notice states that SSL VPN tunnel mode is no longer available in that release and requires migration beforehand. Review the official migration guidance and validate the full gateway, client and identity combination before scheduling the upgrade.
Is installing FortiClient enough to give an employee secure access?
No. The service also depends on a supported gateway design, authentication, permissions, endpoint prerequisites and operational ownership. Confirm that the employee can complete authorised work and cannot reach resources outside the agreed role.
Should personal laptops be allowed?
That is an organisational decision based on support capability and security requirements. Define eligibility, responsibilities and access limits before onboarding them. Verify the selected product capabilities for that endpoint category rather than assuming company-device controls apply automatically.
What should a remote-access pilot include?
Use representative roles, endpoint versions, applications and remote networks. Test enrolment, sign-in, normal work, interruption, denied access and removal. Record the exact conditions so a successful result can be distinguished from an untested assumption.
Who should handle lost authentication devices?
Assign a documented recovery route involving the appropriate identity or support owner. Verify the requester’s identity, limit temporary arrangements and record the outcome. Users should not have to improvise credential sharing to regain access to business work.
Related technology support
For an additional service perspective related to this guide, explore Trubyte’s Fortinet and managed security services.
Discuss your requirements with Maxicon
Tell us about your business, current environment and the support you need.
