Zoho Directory Guide: Identity and Access Lifecycle 2026

The Account That Stayed Open

An auditor asks a simple question: can you show me that people who left the business no longer have access to systems?

The IT manager runs a list. Three accounts belong to people who left, one of them four months ago. All three were disabled in the email system on their last day, which is the step everyone remembers. What nobody did was remove them from the four other applications they had been given access to over the years, because there was no list of what those were.

Nothing bad happened. That is not the point an auditor is making. The point is that nobody could have known if it had.

This is the normal state of affairs in most mid-market businesses, and it is not a discipline failure. Access accumulates one request at a time over years, granted by whoever could grant it, recorded nowhere central. Offboarding removes what somebody remembers.

This article covers what Zoho Directory documents, how to design access around roles rather than requests, the three lifecycle gates and what should happen at each, the mover case that almost nobody handles, and the access review that turns all of it from a project into a control. It is written for IT managers, HR heads and whoever answers the auditor.

The Business Problem: Access Granted by Request

• Access is requested, not derived. Someone needs a system, asks, and is granted it. Reasonable individually, and it means entitlement is a history of requests rather than a reflection of the job.
• There is no inventory of who has what. Each application knows its own users. Nobody holds the combined picture, which is why the auditor’s question is hard.
• Offboarding is a memory exercise. The obvious systems get removed. The ones granted two years ago for a project do not, because nobody remembers them.
• Movers are invisible. Someone changes department and gains the access their new role requires. They keep the access the old role required, because nothing triggers its removal. Over a career this accumulates, and long-serving staff end up with the broadest access in the business.
• Passwords and sign-in vary by system. Different credentials, different policies, different MFA positions, which means the security posture is only as good as the weakest application.
• Nobody can evidence approval. Even where access was properly authorised, the authorisation was a conversation or an email, not a record.
• Shared and service accounts exist and are undocumented. Usually created for a legitimate reason, usually with a password several people know.

What Uncontrolled Access Costs

• Audit findings. The most common trigger for this work. Access control is examined in almost every financial, security and certification audit, and an inability to produce an entitlement list is a finding regardless of whether anything went wrong.
• Risk concentrated in long-serving staff. Not a suspicion about individuals but a structural fact. The people who have been in the business longest have accumulated the most access, and that is where the exposure sits.
• Licence cost on unused entitlement. For per-user applications outside a suite arrangement such as Zoho One, access nobody uses is often still billed.
• Slow onboarding. A new joiner waiting on access requested individually from several administrators is a new joiner not working, which is a cost paid every time someone starts.
• Incident response hampered. When something does go wrong, the first question is who could have done it. Without an entitlement picture, that question takes days.
• Departure risk. An account left active after someone leaves is a risk whose size depends entirely on the circumstances of their departure.

What Zoho Directory Documents

Taken from Zoho’s own product and feature pages, with the caveat that marketing documentation is less specific than administrator documentation and should be verified against the latter before you design around it.

• Single sign-on, giving employees one login across applications.
• Multi-factor authentication, with documented methods including QR codes, time-based one-time passwords and passwordless biometric verification, alongside passwordless MFA through Zoho OneAuth.
• Device authentication, described as letting employees access laptops and desktops with one set of credentials.
• Access management, assigning application access to employees, with role-based or policy-based authorisation across the organisation.
• Conditional access, allowing or denying access based on conditions such as location, device and time.
• Routing policies, which Zoho describes as setting password policy strength and defining which login methods employees use: passwordless, password or social login.
• Directory integration. Zoho states it works with on-premises and cloud directories including Microsoft Active Directory and Azure AD, extending them to multiple cloud applications, with an unspecified “Other Directories” option.
• Provisioning into applications. Zoho’s feature page describes administrators creating and managing user profiles in applications such as Asana from Zoho Directory.
• Integrations. Zoho states a library of 350+ pre-built integrations, naming Dropbox, GitHub, Slack, Zendesk and Tableau among them.
• Reporting. Identity and login reports, customised reporting and user behaviour analysis, described as helping identify security threats.
• A mobile administration app for adding users, assigning applications and viewing the organisation’s workforce identity.

What the public documentation does not specify, and which you should confirm directly rather than assume: deprovisioning behaviour is not described, LDAP and Google directory support are not mentioned on the pages reviewed, SSO protocol support such as SAML, OAuth or OIDC is not specified, and group and organisational unit management and delegated administration are not covered. If any of those are load-bearing for your design, verify them with Zoho or your partner before scoping.

Designing Access Around Roles, Not Requests

This is the shift that makes everything else work, and it is a business exercise rather than a technical one.

• Define access profiles by job, not by person. A sales executive in the east region needs this set of applications with these permission levels. Anyone appointed to that job gets that set; anyone leaving it loses it. Zoho documents role-based or policy-based authorisation, which is the mechanism; the work is deciding what the roles are.
• Start from the actual population, not from an ideal structure. List the jobs that exist, group them where access requirements are identical, and you will usually find a manageable number of distinct profiles. Businesses that try to design the perfect role hierarchy first never finish.
• Separate the standard from the exception. Most people fit a profile. Some need something additional: a system for a specific project, elevated rights for a specific duty. Those should be explicit exceptions with an owner and, ideally, an end date, rather than being absorbed into the profile and inherited by everyone who holds that job afterwards.
• Decide who approves an exception. Usually the application owner plus the line manager. The point is that it is a decision with a name attached rather than an administrator’s judgement under time pressure.
• Accept that the first version will be wrong. Role design improves by contact with reality. Publish it, use it for joiners, and correct it as exceptions reveal themselves, rather than delaying until it is perfect.

The Three Gates: Joiner, Mover, Leaver

Joiner

The trigger should be the HR record rather than an email to IT. When someone is appointed to a job, the profile for that job determines their access. What makes this work in practice is less the automation than the sequencing: access should be ready on day one, which means the trigger has to fire before the start date rather than on it.

Mover

Covered in its own section below, because it is the one that fails.

Leaver

Two things matter and they are different. Disabling sign-in should happen immediately and centrally. This is where single sign-on earns its cost, because one action closes the door rather than seven. Removing entitlement is a separate step, and it matters for the audit question and for licence cost.

There is also a third consideration people forget: what happens to the person’s data and responsibilities. Mailbox access, file ownership, workflows where they are the approver, records where they are the owner. An account disabled without reassigning these creates an operational problem a week later. The leaver process should include it, even though it is not an access question.

Make the leaver trigger HR-driven and same-day. The single most common failure is IT learning about a departure after it has happened. If the HR record is the trigger for access removal, the gap closes structurally rather than depending on someone sending a message.

The Mover Problem Nobody Solves

Joiners get handled because somebody is waiting to work. Leavers get handled because somebody remembers. Movers get handled halfway, every time, and the halfway is always the same half.

When someone changes role, the new access gets granted, because they cannot do the new job without it and they will ask. The old access does not get removed, because nothing and nobody is prompted to remove it.

Repeat that over a few moves and a decade, and you have people with access spanning several departments, none of it improper, all of it accumulated, and collectively the largest access exposure in the business.

Three things fix it:

• Treat a move as a leave and a join. The old profile is removed and the new one applied, rather than the new one being added. This is a process decision more than a technical one, and it is the whole fix.
• Make the HR record the trigger. A role change in the HR record should prompt the access change, in the same way a departure does. Where that connection does not exist, the move will continue to be reported by the employee, who has every incentive to mention the access they need and none to mention the access they no longer require.
• Report movers specifically. A monthly list of people whose role changed in the period, with their current entitlement against their new profile. It is a short report and it is the only way to catch what the process missed.

Multi-Factor Authentication and Conditional Access

Multi-factor authentication is the highest-value control available, and Zoho documents several methods: QR codes, time-based one-time passwords, and passwordless biometric verification, alongside passwordless MFA through Zoho OneAuth.

The implementation question is rarely whether to do it and almost always how to sequence it:

• Start with administrators and finance. The accounts whose compromise matters most, and a small enough population to resolve problems before a wider rollout.
• Pilot each method with real users before standardising. Passwordless approaches reduce friction substantially where devices support them, and create a support problem where they do not. Find out which case you are in with twenty people, not two hundred.
• Plan the recovery path first. The most common MFA rollout failure is not adoption; it is what happens when someone loses their device. Decide the recovery process, who verifies identity, and how quickly, before the first enrolment rather than during the first incident.

Conditional access is the complement. Zoho documents allowing or denying access based on conditions such as location, device and time. Used well, this reduces friction for the normal case (a known device in a known place) while tightening it for the unusual one. Used carelessly, it locks out a director travelling for work, which is a memorable way to lose support for the whole programme.

Routing policies are documented as setting password policy strength and defining which login methods employees use. Worth deciding deliberately per population rather than applying one policy everywhere, since the requirements for a shop-floor shared terminal and a finance workstation are genuinely different.

The Access Review Nobody Schedules

Everything above is implementation. The access review is what turns it into a control, and it is what auditors actually test.

• Review entitlement periodically against roles. Quarterly for privileged access, annually for everyone else. The output is a list of discrepancies (people whose access does not match their profile), not a confirmation that everything is fine.
• Have line managers certify their own teams. IT cannot know whether a particular person still needs a particular system. The manager can. A short, specific list to each manager (here is your team and what they have) produces better results than a central review and distributes the effort sensibly.
• Review privileged accounts separately and more often. Administrator access in any system deserves its own list, its own reviewer and a shorter cycle.
• Inventory shared and service accounts explicitly. They do not belong to a person, so they fall outside a person-based review. Each needs a named owner, a documented purpose and a review date.
• Keep the evidence. Zoho documents identity and login reports with customised reporting and user behaviour analysis. What an auditor wants is the review itself (who certified what, when), so retain it as a record rather than as an exercise someone performed.
• Report three numbers. Accounts not matching their role profile, privileged accounts and their owners, and days from departure to access removal. That last number is the one that answers the auditor’s question before it is asked.

Approaches Compared

Best Practices

1. Define access profiles by job, starting from the jobs that actually exist rather than an ideal hierarchy.
2. Make the HR record the trigger for joiners, movers and leavers.
3. Treat a move as a leave and a join, not as an addition. This single decision fixes the largest accumulation problem.
4. Separate disabling sign-in from removing entitlement in your leaver process; both matter, for different reasons.
5. Include data and responsibility reassignment in offboarding, even though it is not an access question.
6. Roll out MFA to administrators and finance first, and pilot each method before standardising.
7. Decide the MFA recovery path before the first enrolment.
8. Have line managers certify their own teams’ access, quarterly for privileged and annually for the rest.
9. Inventory shared and service accounts separately, each with a named owner and a review date.
10. Report days from departure to access removal. It is the number that answers the audit question.

Common Mistakes

• Designing the perfect role model first. The project never reaches implementation. Publish a rough version and correct it against reality.
• Treating a move as an addition. The single largest source of accumulated access in any business.
• Disabling email and calling it offboarding. Entitlement in other applications survives, which is exactly what the auditor asks about.
• Learning about departures after the fact. If IT is not triggered by the HR record, the gap is structural.
• Rolling out MFA without a recovery path. The first lost device becomes an incident and the programme loses support.
• Conditional access tuned too tightly. Locking out a travelling director is a fast way to have the policy relaxed everywhere.
• Leaving shared accounts out of the review. They are not attached to a person, so a person-based review misses them entirely.
• Central review instead of manager certification. IT cannot judge whether someone still needs a system; their manager can.
• Absorbing exceptions into the profile. The next person appointed to that job inherits access they never needed.
• Assuming undocumented capability. Deprovisioning behaviour, protocol support and group management are not specified on Zoho’s public pages; verify before designing around them.

An Illustrative Scenario: A 200-Person Multi-Site Business

The following is a composite illustration drawn from patterns common to businesses of this size. It is not an account of a specific Techvaria client, and no figures below come from any real engagement.

Consider a two-hundred-person business across three sites, running a mix of suite applications and several specialist systems, with a two-person IT team.

The Trigger

An audit finding. The auditor asked for evidence that leavers’ access had been removed and for a list of who held administrative rights in each system. Neither could be produced quickly, and the exercise of producing them took the IT team most of a week.

What the Exercise Found

Three accounts belonging to people who had left, the oldest four months prior, all disabled in email and active elsewhere. Administrative rights in one specialist system held by five people, two of whom had changed role years earlier. A small number of shared accounts with no documented owner. And no combined view of who had access to what; the information existed, but only inside each application.

The most striking finding was not a breach risk. It was that the people with the broadest access were, without exception, the longest-serving, a direct consequence of moves adding access and never removing it.

What Was Implemented

Role design first, and deliberately rough. The HR team produced the list of jobs; IT grouped them by access requirement, which collapsed into far fewer distinct profiles than anyone expected. The first version was published knowing it was imperfect.

The HR record became the trigger for all three gates. The leaver process separated disabling sign-in from removing entitlement, and added reassignment of ownership (files, approvals, record ownership), which had previously been discovered a week after each departure.

Movers were reclassified as a leave and a join. This was the change that produced the most pushback, because it meant people briefly losing access they were used to having, and it was the change that mattered most.

MFA was rolled out to IT, finance and management first. The passwordless method was piloted with twenty users, which surfaced a device compatibility issue on older hardware that would have been a significant problem at full scale. The recovery process was agreed before the first enrolment.

Quarterly certification was introduced for privileged access and annual certification for everyone else, with managers certifying their own teams from a short list rather than IT reviewing centrally.

What Caught Them Out

Shared and service accounts, which fell outside a person-based review entirely and had to be inventoried separately. And a specialist application that did not integrate as expected, which meant its access remained a manual step, the honest answer being that one system stayed on a checklist while the rest moved to role-derived access.

After Two Quarters

The audit question became a report. Days from departure to access removal, tracked as a number, moved from “variable” to same-day for the systems covered.

The IT manager’s own assessment was that role design had been the hard part and treating movers as leavers had been the valuable part, and that the week spent producing the auditor’s list had, inadvertently, been the business case.

Industry Use Cases

• Healthcare. Access to systems holding patient data makes entitlement review a regulatory matter rather than a housekeeping one, and raises the priority of same-day leaver handling. See healthcare solutions.
• Financial and professional services. The sectors where access control is examined most routinely in audit, and where privileged access review carries the most weight. See professional services.
• Manufacturing. Shared shop-floor terminals and a high proportion of staff without individual devices, which makes routing policies by population more important than elsewhere. See manufacturing solutions.
• IT and technology services. The highest density of administrative rights across systems, and therefore the strongest case for separating privileged access review from the general cycle. See IT services and ERP.
• Education. High joiner and leaver volumes concentrated around term dates, where an HR-triggered process matters more than in businesses with steady turnover. See education solutions.