Clientless access reaches internal applications through a browser session without installing a dedicated client on the person's device.
Convenience is the main benefit, and the tradeoff is that the browser, the session, and the gateway carry risks a managed client might have reduced.
How it works
People open a portal, sign in, and use web based views of mail, files, or remote desktops without a separate install, and that helps contractors, yet a stolen session can matter as much as a missing agent.
Device health checks are harder when you do not control the endpoint through installed software.
Use clientless access for the applications that truly need it, with strong sign in, short sessions, and limits on what the portal can reach.
Record who connected, from where, and which internal app they opened, and do not treat the absence of a client as the absence of a need for monitoring.
Concrete examples
- A contractor reads a project folder through the browser on a personal laptop that the company will never fully manage.
- A stolen portal session lets someone open an internal wiki without installing anything on their own machine.
- A managed client would have checked disk encryption, but the browser path only checked the password and a second factor.
Protective measures
- Restrict clientless portals to the applications and user groups that have a documented need, and review that list each quarter.
- Require strong sign in and short session lifetimes, and recheck identity before downloads or administrative actions.
- Log portal access with user, time, source, and internal application so an investigation is not blind.
- Where you can, prefer a managed client for high risk systems, and keep the browser path for lower risk or temporary work.