TL;DR: The core issue is not automation itself, but whether identity governance can keep pace with discovery, review, and cleanup across human, NHI, and delegated access patterns, according to Josys’ April 2026 release, which adds automated app classification, targeted access reviews, Google Workspace user filtering, API-driven attribute sync, and workflow retry controls to reduce manual governance overhead for SaaS-heavy environments.
At a glance
What this is: Josys’ April release combines app discovery, targeted access reviews, API sync controls, and workflow retry features to reduce manual governance work across SaaS environments.
Why it matters: IAM and IGA teams should care because the release focuses on the operational gap between discovering access changes and consistently certifying, filtering, and correcting them at scale.
By the numbers:
- When adoption grows to 20+ users, Josys can notify teams, evaluate conditions, auto-approve trusted apps, and auto-block unapproved ones.
Context
SaaS governance breaks down when discovery, review, and cleanup are handled as separate manual tasks. In mixed environments, that creates stale access, unapproved apps, and attribute drift that an IGA programme cannot see fast enough.
Josys' April release addresses that operational gap by adding automation across app classification, access review scheduling, Google Workspace user filtering, workflow retries, and field-level sync control. The identity problem here is not one control in isolation, but the lack of coordination between governance decisions and the systems that enforce them.
Key questions
Q: How should teams handle access reviews in fast-changing SaaS environments?
A: Teams should move from periodic, app-by-app certification to centralized review of the full entitlement graph. That means collecting access from SaaS, cloud, identity and HR sources, then prioritizing privileged and business-critical systems first. The goal is to certify effective access, not just listed roles, and to connect review decisions directly to remediation.
Q: Why do unapproved apps create more governance risk than teams expect?
A: Unapproved apps matter because they create an access path outside the normal approval and review process, so policy cannot be enforced at the same speed as adoption. Once users start relying on them, cleanup becomes a catch-up exercise. Teams need detection rules that turn discovery into action before usage hardens.
Q: What breaks when identity attribute sync is all-or-nothing?
A: All-or-nothing sync breaks governance because it can overwrite locally managed fields, erase context, and make downstream access decisions less reliable. That creates silent data drift rather than an obvious failure. The safer approach is to classify fields by ownership before allowing synchronization.
Q: How should teams handle failed workflow automation in identity governance?
A: Teams should treat failed workflow runs as governance exceptions, not as hidden technical noise. If a workflow cannot be retried cleanly, the failure should be triaged against the underlying integration issue and the access or app state it was supposed to change. Otherwise manual fixes become the control.
How it works in practice
Automated app classification and shadow IT response
The release describes event-driven handling for newly discovered apps, where attributes such as compliance, risk, and category are used to classify and act on software as adoption grows. This is a governance workflow, not a security verdict: the system is translating discovery signals into conditional actions such as approval, warning, or block. In practice, that closes the gap between app inventory and policy enforcement, which is where shadow IT usually accumulates. The important mechanism is that discovery becomes actionable before access sprawl hardens into recurring review debt.
Practical implication: Treat new-app discovery as a governed workflow trigger, not a reporting event.
Targeted access reviews and recurring certification
Scheduled and targeted access reviews turn certification into a repeatable control rather than a one-off project. The article ties this to role, department, and risk-based scoping, plus reminders and closure dates, which means the control is being narrowed to the accounts that matter instead of forcing every review to be enterprise-wide. That matters because broad, untargeted recertification often produces low completion and weak reviewer attention. The mechanism is useful when the governance question is not whether to review, but how to keep review scope accurate and sustainable over time.
Practical implication: Use review scoping rules to reduce certification noise and improve reviewer completion quality.
Attribute sync control and workflow reliability
Granular field mapping and manual retry controls solve a different class of governance failure: sync drift and failed automation. When external directories overwrite local values indiscriminately, identity data loses its governance context. When workflow runs fail and cannot be retried cleanly, manual exceptions become the norm. The article’s approach is to make synchronisation selective and reversible enough that identity state remains controllable across systems. That is a practical distinction for teams that depend on clean joins between directory data, access policy, and downstream app provisioning.
Practical implication: Separate source-of-truth attributes from locally managed fields before sync errors create silent data loss.
NHI Mgmt Group analysis
Access governance now fails more often at the coordination layer than at the policy layer. Most teams already have review processes, approval states, and app inventories. The problem is that those controls are not synchronized tightly enough with discovery and sync events to keep pace with SaaS churn. Practitioners should read this as a governance operations problem, not a feature checklist problem.
Targeted certification is a better fit for modern access review workload than blanket review cycles. Reviews scoped by role, department, or risk reduce reviewer fatigue and improve completion quality when identity estates are large and noisy. That does not replace review discipline; it makes the discipline executable. The right question is whether the scoping logic reflects the actual access exposure pattern.
Identity attribute drift is a governance failure because it breaks downstream decisions. If departments, locations, or user profile fields are overwritten without policy control, every downstream approval, reporting rule, and access review inherits bad data. The implication is that synchronisation has to be treated as a governed state transition, not a convenience feature.
Shadow IT automation should be judged by enforcement latency, not by discovery volume. Discovering more apps is not the goal if unapproved usage still lingers long enough to matter. The field needs tighter definitions for when an app becomes reviewable, blockable, or approved, because control value depends on response time, not just visibility.
Recurring access reviews are only defensible when the review boundary stays meaningful. Josys’ release points to a broader market shift toward workflow governance over static certification programmes. The practitioner lesson is to align review cadence, reviewer scope, and automation reliability so the control remains credible under SaaS growth.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Top 10 NHI Issues
What this signals
Shadow IT governance gets harder when discovery is decoupled from enforcement. The release points to a common programme weakness: teams can identify new apps faster than they can classify, approve, or block them. That creates an operational backlog that looks like visibility on paper but behaves like exposure in practice.
Access reviews need to become scope-aware workflows, not calendar events. When reviewers are asked to certify everything, review quality drops and backlog grows. Narrowing the review boundary by role, department, or risk is the difference between a control that runs and a control that merely exists.
For practitioners
- Define governance triggers for newly discovered apps Create explicit conditions for when a new app moves from discovery to approval review, warning, or block so shadow IT is handled consistently.
- Scope access reviews by business relevance Use role, department, and risk filters to limit reviews to the accounts that actually require certification, then pair them with reminder and closure rules.
- Separate managed and local identity attributes Classify each user field as source-controlled or Josys-managed before enabling sync so external directories do not overwrite locally governed values.
- Build retry handling into workflow governance Document which failed workflows can be rerun from history, which must be rebuilt, and which require manual exception handling after the underlying integration issue is fixed.
Key takeaways
- The central governance issue is not whether SaaS automation exists, but whether discovery, certification, and cleanup are coordinated tightly enough to keep pace with change.
- Josys’ release focuses on practical control points such as app classification, targeted access reviews, sync filtering, and workflow retries, which all reduce manual governance friction.
- For practitioners, the key question is whether the control boundary remains meaningful as environments grow, because automation only helps when it shortens enforcement lag.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Recurring reviews and cleanup workflows address stale app and user access left behind. |
| NHI-06 — Insecure Cloud Deployment Configurations | Shadow IT app control depends on policy-driven cloud app enforcement and safe defaults. | |
| Recommendation — Use NHI-01 to remove access paths that remain active after users or apps should no longer be governed. Apply NHI-06 to enforce approved configuration states for newly discovered cloud applications. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Recurring reviews, scoping, and cleanup align with account lifecycle governance. |
| Recommendation — Use AC-2 to ensure account review and removal processes stay current as access changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on controlling entitlements through review and attribute governance. |
| Recommendation — Apply PR.AA-05 to validate entitlements before and during access review cycles. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Unapproved apps and stale access can support post-compromise movement across SaaS services. |
| Recommendation — Map governance gaps that expose SaaS access paths to TA0006 and TA0008 for detection planning. | ||
Key terms
- Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- Attribute Sync: The movement of identity data such as department, location, or custom profile fields between systems. The governance risk is not synchronisation itself, but uncontrolled overwrites that corrupt downstream policy decisions and reporting.
- Workflow Retry: The ability to re-run an automated process after a failure without rebuilding the workflow from scratch. In identity operations, retries matter when integration errors or transient issues interrupt provisioning, review, or approval paths.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org