Harvest access governance via Zluri and the identity gap it exposes

At a glance

What this is: This is an analysis of Zluri’s Harvest integration and its implications for access discovery, lifecycle governance, and role-based restrictions in SaaS administration.

Why it matters: It matters because the same provisioning, deprovisioning, and access-review patterns that govern SaaS tools also shape broader IAM, NHI, and lifecycle controls across the enterprise.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's article on Harvest automation, provisioning, and access control

Context

Access governance fails when teams rely on manual steps to add, remove, and review users across SaaS applications. In Harvest, the relevant identity question is not time tracking itself but whether access, billing rights, and deprovisioning are consistently tied to lifecycle changes and role changes.

That problem is familiar to IAM and IGA teams because lifecycle drift creates the same control gap across human users, service accounts, and other non-human identities. When access reviews happen after the fact and revocation is inconsistent, the organisation is left with stale permissions, shadow usage, and avoidable audit exposure.

Key questions

Q: How should organisations govern SaaS provisioning and deprovisioning?

A: Organisations should govern SaaS provisioning and deprovisioning as lifecycle controls, not as ad hoc admin tasks. Every account creation, role change, and removal should map to a documented business event, a named owner, and a confirmed revocation step. The goal is to prevent access from outliving the need that justified it.

Q: Why do manual offboarding processes create identity risk?

A: Manual offboarding creates identity risk because it depends on people remembering every connected system and every entitlement path. That increases the chance of missed revocation, especially in SaaS stacks with billing, reporting, and delegated admin functions. Stale access then remains active long after the relationship ends.

Q: How do access reviews help reduce SaaS sprawl?

A: Access reviews reduce SaaS sprawl by forcing teams to confirm whether active users, inactive users, and assigned licences still match business need. When paired with discovery, reviews expose duplicate tools, unused accounts, and permissions that no longer match current roles. That makes cleanup measurable instead of anecdotal.

Q: Who should approve access to sensitive application functions?

A: Sensitive application functions should be approved by the role owner, not inherited automatically from basic application access. If billing visibility, invoice creation, or similar actions carry financial impact, they need explicit entitlement approval and periodic revalidation. That keeps high-risk capabilities tied to present job function rather than historical access.

Technical breakdown

Provisioning and deprovisioning as identity lifecycle controls

Provisioning is the act of granting the right access when a user joins or changes role, while deprovisioning removes access when that relationship ends. In SaaS environments, those steps often span multiple systems, which is why lifecycle automation matters more than simple admin convenience. If the workflow only creates accounts but does not reliably revoke them, the organisation accumulates dormant entitlements that remain valid long after business need has ended. That is a governance problem, not just an operational one.

Practical implication: map every onboarding and offboarding step to a named control owner and verify that revocation is enforced as consistently as creation.

Role-based access and billable rate restrictions

Role-based access control limits what a user can see or do based on assigned job function. In the Harvest example, access to billable rates and invoicing is restricted to project managers, which is a narrow entitlement decision rather than broad application access. That distinction matters because fine-grained entitlements reduce unnecessary exposure when a user only needs partial access. The governance challenge is keeping role assignments accurate as people move between teams or leave the organisation.

Practical implication: review sensitive application permissions separately from basic login access so high-risk functions stay tied to current job role.

User access reviews and discovery for shadow app visibility

User access reviews validate whether a person still needs the access they hold, while discovery shows which apps and accounts are actually in use. Zluri’s framing connects those two tasks because visibility without review does not fix stale entitlement risk. The same pattern applies across SaaS and identity programmes more broadly: if you cannot see who is active, who is inactive, and which accounts are tied to which business purpose, you cannot govern access with confidence. Discovery is the starting point, not the control outcome.

Practical implication: combine app discovery with periodic access recertification so inactive accounts and unused licences are removed before they become audit issues.

NHI Mgmt Group analysis

Access lifecycle, not feature richness, is the real control boundary in SaaS governance. The Harvest example shows that the meaningful security question is whether access can be created, narrowed, and revoked as roles change. A tool may improve operational efficiency, but the programme succeeds or fails on whether entitlements are kept current. Practitioners should treat lifecycle correctness as the control objective, not admin convenience.

Manual deprovisioning creates a standing access problem even when the application itself is benign. The article describes the risk of missing a system or failing to revoke access promptly, which is the classic failure mode in identity programmes with too much human intervention. That gap is not unique to people. The same pattern appears whenever access persists beyond the business event that justified it, including service accounts and other non-human identities. Practitioners should see offboarding as a control that expires privilege, not a task checklist.

Shadow app visibility and user access reviews belong in the same governance loop. The article connects app discovery, user engagement, and access reviews, which is the right model for SaaS sprawl. Discovery answers what exists, while recertification answers whether it should still exist for that user or role. Without both, organisations overestimate control maturity. Practitioners should align discovery output with review cadence and entitlement cleanup.

Billable-rate access is a reminder that sensitive functions need separate entitlement logic. Harvest does not just store user accounts; it also exposes financial workflow functions that should not travel with every login. That is a useful illustration of granular access design across human IAM and adjacent lifecycle governance. Practitioners should isolate sensitive application actions from ordinary user access and track them as distinct entitlements.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often discovery and governance remain disconnected.
• For a broader lifecycle lens, review NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Lifecycle automation is becoming the minimum viable control for SaaS access governance. The more applications an organisation manages, the less reliable manual deprovisioning becomes. Teams should expect lifecycle controls to be evaluated alongside discovery quality and review cadence, especially where billing, finance, or customer data workflows depend on application entitlements.

A useful named concept here is access persistence debt, the gap created when permissions survive longer than the business reason for granting them. That debt accumulates across humans and non-human accounts alike, and it is hardest to see in applications that look operational rather than security-critical.

The practical signal for IAM leaders is simple: if discovery, review, and revocation do not operate as one loop, the organisation is managing SaaS access reactively. Teams that want fewer audit exceptions should connect licence management to offboarding evidence and periodic access recertification.

For practitioners

• Tie deprovisioning to the business event Make offboarding an enforced workflow, not an optional admin task, so access removal happens when employment or role change is recorded.
• Separate privileged app functions from standard access Treat billing visibility, invoicing, and other high-risk functions as distinct entitlements that require explicit role assignment and periodic review.
• Reconcile discovery against active user lists Use app discovery and licence reports to identify inactive users, stale assignments, and shadow app usage before renewal or audit cycles.
• Run access reviews on a fixed cadence Validate who still needs access to Harvest and similar SaaS tools, then remove permissions that no longer match current job function.

Key takeaways

• The core risk is not Harvest itself but the lifecycle drift that appears when access is added and removed manually across connected SaaS tools.
• The article’s own example shows that discovery, inactive-user cleanup, and role-based restriction are the controls that keep access bounded.
• IAM and IGA teams should treat provisioning, deprovisioning, and access reviews as one operating model rather than separate admin tasks.

Key terms

• Provisioning: Provisioning is the process of granting a user or system the access needed to perform a role or task. In identity governance, it must be tied to a business justification, a specific entitlement, and a clear owner so access does not become broader or longer-lived than intended.
• Deprovisioning: Deprovisioning is the removal of access when a user no longer needs it, usually because of a role change, offboarding, or contract end. It is a control outcome, not an administrative courtesy, because delayed revocation leaves unnecessary permissions active.
• Access review: An access review is a periodic check that confirms whether an identity still needs the permissions it currently holds. It is most effective when paired with discovery and revocation evidence, so the organisation can correct stale entitlements instead of merely recording them.
• Role-based access control: Role-based access control assigns permissions through job functions rather than one-off exceptions. It helps reduce overexposure in applications like Harvest by keeping sensitive actions, such as invoicing or billable-rate visibility, linked to a role that can be reviewed and changed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Automation How to Get More Out of Harvest Via Zluri’s Integration? Read the original.