A Freshservice service desk holds tickets, asset records and onboarding requests, and its workflows can call other systems with stored credentials, so the accounts and keys that drive it deserve privileged handling. IT service management platforms sit next to identity, HR and infrastructure tools, which makes them a busy hub for both people and automation. This guide explains how to secure Freshservice from the customer side: Freshworks organisation sign-in policies and SSO, mandatory 2FA, agent roles and scopes, API keys and integration users, Workflow Automator web requests and the credential store, IP restrictions, and the audit log. It is written for Freshservice administrators, IT operations leads and SaaS security teams. For the general SaaS control model see the SaaS Security Guide; this page stays specific to Freshservice.
This is an independent guide from NHI Mgmt Group, based on Freshservice's public documentation as of November 2026. It is not sponsored or reviewed by Freshservice. Product features change, so confirm settings against Freshservice's current documentation.
Key takeaways
- Sign-in is set at the Freshworks organisation. The default security policy covers every admin and agent, and combines Freshworks login, Google Login and SSO (SAML 2.0, OIDC, OAuth 2.0 or JWT).
- Mandate 2FA wherever passwords remain. Freshworks documents mandatory 2FA for org admins and lets org admins enforce 2FA as a policy for all or some users; confirm plan availability in the Freshworks documentation.
- Use integration users for automation. Freshservice integration users have their own API key, cannot sign in to the web interface, need no agent licence and show up by name in the audit log.
- An API key carries its owner's permissions. Requests run as the agent who owns the key, so an admin's key used in a workflow carries admin reach.
- Keep workflow secrets in the credential store. The Centralized Credential Store holds Basic, API key and OAuth 2.0 credentials for web request nodes and webhooks, so one change rotates them everywhere.
How identity and access work in Freshservice
Freshservice is part of a Freshworks organisation, and sign-in for agents and admins is governed there, through the organisation URL and its Security page. The default security policy applies to all users in the organisation, including admins and agents. It can combine three login methods: Freshworks login (email and password, governed by a password policy), Google Login and SSO login. Custom policies can apply different rules to agents in a specific account or portal. Within Freshservice, Org Admins reach SSO through Admin > Account Settings > Service Desk Security.
| Login method | Where set | Options in Freshworks docs | Recommended use |
|---|---|---|---|
| SSO login | Organisation Security page, default or custom policy | SAML 2.0, OpenID Connect, OAuth 2.0, JWT; guides for Okta, Azure AD (Microsoft Entra ID), ADFS and OneLogin | Primary method, so MFA and conditional access come from your identity provider |
| Freshworks login | Security > Default Login Methods > Freshworks Login | Password policy; 2FA section with Mandate 2FA | Keep only for break-glass accounts, with 2FA mandated |
| Google Login | Default security policy | On or off | Turn off where SAML or OIDC SSO is in place, so one route governs sign-in |
| Mandate 2FA | Freshworks Login edit page, 2FA section | All users (with optional exceptions), organisation admins only, specific users, or Don't mandate 2FA | All users, with exceptions documented and reviewed |
| Org admin 2FA | Applies automatically on paid plans | Authenticator app (TOTP, recommended) or email OTP; recovery codes at setup | Use an authenticator app and store recovery codes in a vault |
The Mandate 2FA policy applies only when Freshworks login is enabled, and once 2FA is turned on for a mandated user they cannot switch it off. When SSO is the only login method, MFA strength comes from your identity provider; see the Identity Provider and SSO Security Guide and the SAML Security Guide.
IP restriction: under Service Desk Security, admins can enter allowed IP ranges and apply each range to agents, requesters or both. Use it for agent access from office and VPN egress addresses, and pilot it before enforcing, since a missing range locks out remote staff.
Admin roles and privileged access
Freshservice separates admin roles, which control the Admin section, from agent roles, which control daily work on tickets, problems, changes, assets and other modules. On accounts with workspaces, roles can be granted account-wide or per workspace.
| Role or permission | Effect (Freshservice docs) | Least-privilege guidance |
|---|---|---|
| Org Admin (Freshworks organisation) | Configures organisation security policies and SSO; 2FA required on paid plans | Two or three named people with authenticator app 2FA |
| Account Admin | Full admin control including plans, billing and workspaces; default admin access to settings of every workspace; no data access without an agent role; no access to restricted workspaces | Small group; do not pair with broad agent roles by habit |
| Workspace Admin | Configures all features in a workspace; assignment also grants IT Supervisor data privileges by default | Review the paired IT Supervisor role and remove it where not needed |
| IT Supervisor and IT Agent | All non-admin actions (IT Agent without reporting) | Use specialised roles (Change Manager, Problem Manager) where they fit |
| Custom roles | Admin > Global settings > Roles > New Role; privileges per module, scoped to modules such as Tickets, Changes, Contracts, Purchase Orders, Onboarding and Offboarding requests | Build roles for sensitive modules such as onboarding, offboarding and contracts |
| Integration user admin rights | View, create, edit, delete integration users; reset API keys; reactivate | Restrict to the platform owner team |
Scope of data access
Each agent's role is paired with a scope. On single-workspace accounts the levels are: access across all groups in the helpdesk; access to groups the agent belongs to as member or observer; access to specific groups; and restricted access, where the agent sees only items assigned to them. Choose group-based scope as the default, keep all-groups scope for supervisors, and use restricted groups or restricted workspaces for HR, legal and security tickets.
Freshworks Support access
Admins can grant Freshworks support staff temporary access under Admin > Agents > Freshworks Support > Manage Access with the Provide access to Freshworks toggle. Access defaults to one week, can be set up to 30 days, is limited by role and workspace, and can be revoked at once by turning the toggle off. Our recommendation: grant it per support case, for the shortest period that works, and check See who has access afterwards. See the SaaS Admin Account Protection guide.
Integrations, API tokens and service accounts
Freshservice's REST API authenticates with an API key sent through HTTP Basic authentication, with the key as the username. Username and password Basic authentication was retired in June 2023, and all calls must use HTTPS. Requests run with the permissions of the agent who owns the key, so the key is exactly as powerful as that person's role and scope.
| Identity for automation | How it works | Security handling |
|---|---|---|
| Agent personal API key | Shown in the agent's profile settings; inherits the agent's role and scope | Use for personal scripting only; never embed a person's key in shared automation |
| Integration user | Created under Global Settings > User Management > Integration Users; own API key; no web, mobile, password or SSO login; no agent licence; up to 5 (Starter, Growth) or 20 (Pro, Enterprise) | One integration user per integration, with only the workspace and account roles it needs; reset its key if exposed |
| Credential store entry | Admin > Automation & Productivity > Credentials; Basic Auth, API key, No Auth or OAuth 2.0 (authorisation code or client credentials) | Reference from web request nodes and webhooks instead of typing secrets into each workflow |
| Marketplace and orchestration apps | Installed apps and orchestration connectors that call Freshservice or other systems | Approve each with an owner; review installed apps quarterly |
Integration users solve the classic leaver problem: Freshservice notes that automation keeps running when an employee leaves, and machine actions appear under the integration user's display name in audit logs and ticket activity. Resetting an integration user's key, or deactivating it, stops every app and automation that uses it, which makes both actions useful containment steps. See the Service Account Security Guide and the SaaS API Token Security Guide.
Workflow Automator web requests
The Web Request node lets a workflow call any REST API and branch on the response, for example creating an account in a directory during onboarding. It supports Basic Auth (including a Freshservice API key as username), API Key and No Auth. Practical guidance:
- Credentials: store them in the Centralized Credential Store and reference them, so rotation is one change and secrets are not copied into many workflows.
- Least privilege: Freshservice examples sometimes use an admin API key. Use an integration user whose role covers only the calls the workflow makes.
- Prefer OAuth 2.0: where the target supports it, use an OAuth 2.0 credential with the narrowest scope; see the Machine-to-Machine OAuth (Client Credentials) Guide.
- Private endpoints: reaching internal APIs requires allow-listing Freshservice's published regional IP addresses, or routing through the Orchestration Server for on-premises systems. Limit those allow-list entries to the specific endpoints the workflow needs.
- Change control: treat workflows that create accounts, grant groups or reset passwords as privileged code, with peer review before activation.
Logging and detection
The Freshservice audit log sits at Admin > Global Settings > Account Settings > Audit Log (or the workspace equivalent). It records administrative actions, security updates and configuration changes, including agent and group changes, 2FA toggles and security settings updates. Each entry shows the timestamp, what changed, the action, who performed it with their IP address, and the workspace. Ticket, problem and change events appear in each record's Activity section instead.
| Source | Retention and access | Detection use |
|---|---|---|
| Audit log (UI) | Six months on all plans; filter by workspace, date, user and change type | Review admin, role and security setting changes |
| Audit log export | Last 90 days, full or filtered, emailed to the requester | Evidence for access reviews and investigations |
| Audit Log API | JSON with timestamp, module, action, user, IP, workspace and modified fields; incremental fetching | Scheduled feed into your SIEM to keep history beyond six months |
| Service Desk Security notifications | Email to named agents when an agent is added, an agent is deleted or IP restriction is modified | Fast signal for privilege and access changes |
| Ticket Activity | Per-record history, including automations run by integration users | Trace what a workflow or integration changed |
Our recommendations for alerting in the SIEM: new or changed admin roles, agent creation outside the joiner process, changes to SSO or 2FA settings, IP restriction edits, and actions by integration users outside their normal module. API rate limits are applied per account per minute (100 on Starter up to 500 on Enterprise, per the API docs), so sustained 429 responses can also point to a runaway or misused integration. See the SaaS Audit Log Retention and Licensing Guide.
Metrics that show it is working:
- Share of agents signing in through SSO or with 2FA mandated (target 100%).
- Number of Account Admins, Workspace Admins and Org Admins (trend down, each named).
- Automations using personal agent API keys (target zero, all moved to integration users).
- Workflows with inline credentials rather than credential store references (target zero).
- Audit log days held in the SIEM (target at least your retention policy).
- Freshworks Support access grants open longer than the support case.
Hardening baseline
A phased rollout. Each step can be rolled back by reverting the same setting, and the organisation default policy should be changed only after a pilot custom policy succeeds.
- Inventory: list Org Admins, Account and Workspace Admins, agents with all-groups scope, integration users, stored credentials and workflows with web request nodes.
- Turn on notifications: set Service Desk Security notifications for agent added, agent deleted and IP restriction changes to a monitored group.
- Configure SSO: set up SAML or OIDC with your identity provider on a pilot policy, then make it the default login method.
- Mandate 2FA: for any remaining Freshworks login, mandate 2FA for all users and document exceptions.
- Turn off Google Login where SSO is in place, so sign-in has one governed route.
- Reduce admin roles: trim Account and Workspace Admins and remove default IT Supervisor pairings that are not needed.
- Set scopes: move agents to group-based scope and restrict sensitive groups and workspaces.
- Create integration users: move every integration and workflow off personal agent keys, one integration user each.
- Move secrets to the credential store: replace inline workflow credentials, preferring OAuth 2.0 where the target supports it.
- Apply IP restriction for agents after a pilot, and feed the Audit Log API into your SIEM.
| Organisation size | Priority choices |
|---|---|
| Small IT team | Mandate 2FA for all, two admins, integration users for each connector, quarterly audit log export |
| Mid-size | SSO as default, group-based scope, credential store for all workflows, notifications on |
| Large or multi-workspace | All of the above plus restricted workspaces, custom admin roles, SIEM feed from the Audit Log API and IP restriction for agents |
Common misconfigurations
- An admin's key in a workflow: web requests authenticated with an admin API key carry full admin reach. Use a scoped integration user.
- Automation on a person's key: integrations stop or keep running under a leaver's identity. Move them to integration users.
- Secrets typed into nodes: credentials copied into many workflows are hard to rotate. Reference the credential store.
- Several login routes left open: SSO configured while Freshworks login and Google Login stay on without mandated 2FA. Choose one governed route and mandate 2FA on the rest.
- Workspace Admins with full data access: the default IT Supervisor pairing gives broad data access. Review it for each Workspace Admin.
- Audit history allowed to age out: six months in the UI is shorter than many retention policies. Pull the Audit Log API into the SIEM.
Apply Freshworks security updates and notices as they are published, and run leavers through the SaaS deprovisioning process.
Framework mapping
| Freshservice control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SSO, Mandate 2FA, password policy | IA-2, IA-5 | PR.AA-01 | T1078.004 Cloud Accounts |
| Admin and agent roles, scopes | AC-2, AC-6 | PR.AA-05 | T1213 Data from Information Repositories |
| Integration users and API key resets | IA-5, AC-6 | PR.AA-01 | T1528 Steal Application Access Token |
| Credential store and app review | SA-9, CM-7 | GV.SC-07 | T1550.001 Application Access Token |
| Audit log, API feed and notifications | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- Default security policy uses SSO; Google Login turned off where SSO is in place.
- Mandate 2FA set to all users for any Freshworks login, with exceptions documented.
- Org Admins, Account Admins and Workspace Admins limited to named people and reviewed quarterly.
- Agents on group-based scope; sensitive groups and workspaces restricted.
- Every integration and workflow runs as an integration user with a minimal role.
- Workflow credentials held in the Centralized Credential Store, OAuth 2.0 preferred.
- IP restriction applied for agents after a pilot.
- Service Desk Security notifications on for agent and IP restriction changes.
- Audit Log API feeding the SIEM; exports kept as review evidence.
- Freshworks Support access granted per case and revoked when the case closes.
Standards and references
- Freshservice: Configuring SSO in Freshservice
- Freshworks: How to enforce 2FA as a policy for all or some users
- Freshservice: Understanding roles for agents
- Freshservice: Manage integration users
- Freshservice: Centralized credential store
- Freshservice: Web request node
- Freshservice: Audit log
- Freshservice: API documentation
Related NHI Mgmt Group resources: SaaS Security Guide, Service Account Security Guide, SaaS API Token Security Guide, Identity Provider and SSO Security Guide, SaaS and OAuth App Governance Guide.