Zoho One and Zoho CRM Security: Hardening Directory, CRM Roles, OAuth and Audit

Zoho One puts dozens of business applications behind one Zoho Directory identity, so a single over-privileged admin, a loose security policy or a forgotten OAuth refresh token can reach CRM, finance and HR data at once. This guide explains how to secure the two layers most organisations care about first: Zoho Directory (the identity and policy layer for Zoho One) and Zoho CRM (profiles, roles, data sharing, Marketplace extensions and API access). Product facts come from Zoho's own help and developer documentation, checked on 8 November 2026; hardening stances, alerts and metrics are NHI Mgmt Group guidance. These are customer-side settings under the shared responsibility model. It is written for Zoho administrators, identity teams and security engineers who own a Zoho One or Zoho CRM tenant. For the wider SaaS programme around it, see the SaaS Security Guide.

This is an independent guide from NHI Mgmt Group, based on Zoho's public documentation as of November 2026. It is not sponsored or reviewed by Zoho. Product features change, so confirm settings against Zoho's current documentation.

Key takeaways

• Directory is the front door. Security policies in Zoho Directory combine password policy, MFA, allowed IPs and session management, and apply to every Zoho One app a user signs in to.
• Use the delegated admin roles. Zoho One separates Organization Owner, Organization Admin, Application Admin, Helpdesk Admin, Security Admin and Space Admin, so most people who administer something need far less than full admin.
• CRM access has two axes. Profiles decide what features and modules a user can use; roles in the hierarchy decide whose records they see. Data sharing rules and record sharing widen both.
• Refresh tokens are long-lived non-human credentials. Zoho documents a refresh token as valid until revoked, so every Self Client and integration needs an owner, narrow scopes and a revocation path.
• Two audit trails, one picture. The Directory audit log covers admin and account activity; the CRM audit log covers record, export and setup changes for three years, with login history kept separately.

How identity and access work in Zoho One and Zoho CRM

Zoho One users live in Zoho Directory. Directory holds users, groups, applications and security configuration, and its Admin Panel is where policies, admins and audit logs are managed. Inside each application, such as Zoho CRM, a second layer of application permissions decides what the signed-in user can do with data. Integrations and scripts reach the APIs through OAuth 2.0 clients registered in the Zoho developer console.

Security policies and MFA

A Directory security policy has four components: password policy, MFA, allowed IPs and session management. To set MFA, go to Admin Panel > Security > Security Policies, select the policy, open Multi-factor Authentication, click Setup, choose the allowed modes and click Update Policy. Zoho documents these modes:

Once MFA is enabled for a user, Zoho requires them to set up a mode before they can sign in. Create a separate, stricter security policy for administrators and use Add User to Policy to place every admin in it; use Exclude User from Policy only for documented exceptions. See the Phishing-Resistant MFA Guide.

Single sign-on

Directory can act as the identity provider for connected applications, exchanging identity provider and service provider details per app, and it can also sign users in through an external identity provider using Custom Authentication. Decide which system is authoritative. If an external identity provider signs users in, enforce MFA and conditional access there and keep the Directory admin accounts on a Directory policy with hardware keys, so an outage or compromise of the external provider does not lock you out or hand over admin access. See the Identity Provider and SSO Security Guide.

Admin roles and privileged access

Zoho One documents a set of system roles plus custom roles and per-application service admins.

• MFA resets are privileged: Disable MFA and Reset MFA require the Organization Owner or Organization Admin role and password verification. A reset forces the user to enrol again at next sign-in, which is exactly what a social engineer wants, so require a verified ticket before any reset. See the Vishing and Help Desk Social Engineering Awareness Guide.
• Keep admin identities separate: give admins a dedicated administrative account where practical, so daily email and browsing do not run with admin rights.
• Break-glass: keep one documented emergency admin path that does not depend on the external identity provider, protected by a hardware key and tested twice a year. See the Break-Glass Account Guide.

CRM profiles, roles and sharing

Zoho CRM ships default Administrator (all features) and Standard (limited features) profiles, plus a Team User Profile when team users exist; only the org module permissions of default profiles can be changed. Create custom profiles under Setup > Security Control > Profiles > New Profile by cloning an existing profile; this needs the Manage Profiles permission. Clone from Standard and add what the job needs, rather than cloning Administrator and removing rights.

1. Profiles: set module and feature permissions per job family. Pay particular attention to export, mass update, mass delete and data administration features, which turn a single account into a bulk data channel.
2. Roles: build the hierarchy to match reporting lines. Users see their own records and those of subordinates, so a role placed too high quietly grants wide visibility.
3. Data sharing rules and record sharing: these extend access to peers, management and subordinates. List every rule, give it a business reason and remove rules nobody can explain.
4. Territories: segment accounts by region, product or industry where ownership alone is not enough.
5. Allowed IPs: restrict CRM sign-in to known networks for administrator and finance profiles where your workforce model allows it.

See the Least Privilege Techniques Guide.

Integrations, API tokens and service accounts

OAuth clients and the Self Client

Zoho APIs use OAuth 2.0. Zoho documents that an access token is valid for one hour (expires_in 3600) and that a refresh token has an unlimited lifetime until it is revoked. The web-based grant token is valid for two minutes. A Self Client, created in the developer console by choosing the Self Client type and clicking Create Now, suits back-end jobs with no redirect URL: the developer generates a short-lived code for chosen scopes and exchanges it for tokens. Tokens are refreshed with a POST to {Accounts_URL}/oauth/v2/token on the data centre's accounts domain, such as accounts.zoho.com, accounts.zoho.eu or accounts.zoho.in, and Zoho documents that a refresh token generated for one organisation or environment cannot be used for another, for example production versus sandbox.

• Scope narrowly: scopes follow service.scope.operation. ZohoCRM.modules.ALL grants every module; ZohoCRM.modules.leads.READ grants read on one module. Zoho's documentation notes that separate, narrower scopes improve security.
• Who grants matters: API calls run with the rights of the user who authorised the client. Authorise integrations from a dedicated integration user on a custom profile, not from a personal administrator account, so the token's reach is bounded and does not vanish or widen when a person changes role.
• Revocation path: Zoho documents that users can revoke delegated access at any time. Record how each integration is revoked and test it, so a leaked token can be killed in minutes.
• Keep tokens out of code: Zoho states that access tokens must not appear in public repositories, forums or client-side code. Scan repositories for Zoho tokens and client secrets.

See the OAuth Refresh Token Rotation Guide and the Service Account Security Guide.

Marketplace extensions

Extensions add code and connections inside CRM. They are installed from Setup > Marketplace > All, and the install dialog offers Install for admin only, Install for all users or Choose profiles, followed by an authorisation step for any connected third-party service. Public extensions go through a Zoho review before listing; private extensions are shared by URL. Treat every extension as a third-party integration:

1. Require a request and an owner before install, with the data the extension will read or write written down.
2. Install to selected profiles, not all users, unless every user genuinely needs it.
3. Prefer public, reviewed extensions; treat privately shared extension URLs with extra scrutiny.
4. Review installed extensions quarterly and uninstall unused ones. Zoho documents that uninstalling can delete the extension's related data, so export anything you need first.

See the Consent Phishing and Illicit OAuth Grants Guide.

Logging and detection

Zoho Directory's audit log is at Admin Panel > Audit > Audit Logs, visible to Organization Owners and Organization Admins, and groups activity by type with the affected user and timestamp. The Directory getting-started guidance also points admins to authentication activity, security events and anomaly detection. The Zoho CRM audit log, at Setup > Security Control > Audit Log, records record additions, updates and deletions, imports, exports, lead conversions, restores, mass actions and setup changes such as workflow rules, webhooks, roles, profiles, users and webforms. Zoho keeps CRM audit entries for three years and then deletes them; Export Audit Log produces a CSV. CRM sign-ins are in Setup > Security Control > Login History, not the audit log. Administrators and users with the CEO role see all users' entries; others see their own and their subordinates'.

Because CRM entries age out after three years, export both Directory and CRM logs on a schedule to your SIEM or archive and keep them for the period your policy requires. See the SaaS Audit Log Retention and Licensing Guide and the SIEM Guide.

Metrics: percentage of admins on hardware key MFA (target 100); number of Organization Admins (target three or fewer); OAuth clients with a named owner (target 100 percent); extensions installed for all users versus selected profiles; days since last audit log export; MFA resets without a matching ticket (target zero).

Hardening baseline

Roll out in this order, testing each step on a pilot group before the whole organisation, and keep the previous policy settings recorded so you can roll back.

1. Inventory: export users, admins (all roles and service admins), groups, applications, CRM profiles, roles, sharing rules, extensions and OAuth clients.
2. Admin policy first: create an admin security policy with Yubikey or OneAuth biometric MFA only, short sessions and allowed IPs, and add every admin to it. Pilot with two admins, then the rest.
3. Organisation policy: enable MFA for all users with SMS removed where possible, set password requirements and session controls. Announce, pilot one department, then enforce.
4. Conditional access: restrict high-value apps by IP or device conditions where your plan includes Conditional Access Policy.
5. Delegate: move people from Organization Admin to Application, Helpdesk, Security or Space Admin or a custom role.
6. CRM: rebuild profiles from Standard, review export and mass-action rights, align the role hierarchy, prune sharing rules.
7. Integrations: re-authorise integrations from dedicated integration users with narrow scopes, move tokens into a secrets manager, revoke the old ones.
8. Logging: schedule exports of both audit logs and CRM login history, and build the alerts above.

Common misconfigurations

• Everyone who administers anything is an Organization Admin: use the delegated system roles and custom roles instead.
• One security policy for all: admins share the general policy, SMS included. Put admins in their own stricter policy.
• Integrations authorised by a personal admin account: the refresh token carries full admin reach and breaks or persists unpredictably when that person changes role. Use a dedicated integration user.
• Broad scopes: ZohoCRM.modules.ALL requested by default when the integration reads one module. Request module and operation scopes.
• Extensions installed for all users: choose profiles, record an owner and review quarterly.
• Audit logs never exported: CRM entries are deleted after three years and are often needed for investigations and audits. Export on a schedule.

Framework mapping

Practitioner checklist

• Keep one Organization Owner and three or fewer Organization Admins, all on hardware key MFA.
• Create a dedicated admin security policy with strong MFA modes, short sessions and allowed IPs.
• Enforce MFA for all users and remove SMS wherever another mode works.
• Delegate through Application, Helpdesk, Security and Space Admin or custom roles.
• Require a verified ticket before any MFA reset and alert on every reset.
• Build CRM custom profiles from Standard and restrict export and mass actions.
• Authorise every integration from a dedicated integration user with module-level scopes, and store refresh tokens and client secrets in a secrets manager.
• Install Marketplace extensions to selected profiles with a named owner; review quarterly.
• Export Directory and CRM audit logs and CRM login history to your SIEM on a schedule.
• Test the break-glass admin path and an OAuth token revocation twice a year.

Standards and references

• Zoho: Admins and Roles Overview, Zoho One Admin Guide
• Zoho: Security Policies, Configure MFA, Zoho Directory Admin Guide
• Zoho: View Audit Logs, Zoho Directory
• Zoho: CRM API OAuth 2.0 Overview
• Zoho: CRM API Scopes
• Zoho: FAQs on Audit Logs, Zoho CRM
• Zoho: Managing Profiles, Zoho CRM
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: SaaS Security Guide · Identity Provider and SSO Security Guide · OAuth Scope Design Guide · Service Account Security Guide