Josys March release tightens SaaS governance and workflow control

At a glance

What this is: Josys’ March release combines SaaS reporting, device visibility, action prioritisation, and workflow automation into a single governance flow for discovered apps and MDM-linked assets.

Why it matters: It matters because identity teams need a way to coordinate app, device, and lifecycle actions without losing control of approval, timing, or access revocation across fragmented environments.

Context

This release is about SaaS governance, not just task automation. The problem it addresses is fragmented visibility across apps, devices, and workflows, where IT teams can see risk in one system, ownership in another, and lifecycle actions in a third.

For identity and access programmes, that fragmentation creates delayed offboarding, inconsistent app classification, and weak control over shadow users. Josys’ March update tries to collapse those steps into a single operational view so governance decisions happen closer to discovery and event timing.

Key questions

Q: What breaks when SaaS discovery is not connected to governance workflows?

A: Discovery becomes reporting instead of control. If newly found applications are not routed into ownership, certification, and remediation processes, teams may know an app exists but still fail to manage access, licensing, or offboarding. The result is a visible inventory with no governance effect.

Q: Why do shadow users and unused licences become access risks as well as cost issues?

A: Because they often signal accounts or applications that still exist outside normal lifecycle control. Once an identity or app remains active without clear ownership, it can carry access, data exposure, or policy exceptions that are harder to detect than pure financial waste.

Q: How should teams decide which SaaS workflows to automate first?

A: Start with repetitive, high-volume, and time-sensitive workflows that create the most manual bottlenecks, especially app requests, renewals, and joiner-mover-leaver steps. These processes have the highest return on automation because they combine operational load with governance impact, making failures expensive in both time and risk.

Q: How should security teams govern workflow automation in SaaS-heavy environments?

A: Security teams should treat workflow automation as part of the identity control plane, not as a separate operations layer. Every automated step that assigns, renews, monitors, or revokes access should have an owner, evidence trail, and exception path. Without that structure, automation scales the wrong decision as efficiently as the right one.

How it works in practice

Unified reporting for SaaS governance and license control

The new reporting module combines app usage, license data, security insights, and device inventory in one dashboard. That matters because governance teams usually need multiple system views to answer a single question about risk, ownership, or cost. Exportable reports in CSV, XLS, and PDF extend the output beyond inspection into audit and operations workflows. RBAC on the reporting layer also matters because visibility itself becomes a governed asset when reports expose sensitive access patterns or device assignments.

Practical implication: Use a single reporting layer to correlate SaaS risk, license waste, and device ownership before routing cases into access or procurement workflows.

Discovered apps and automated workflow triggers

Discovered apps are applications identified by the platform’s discovery engine before they are formally governed. The release extends workflows to those apps, allowing classification by usage, risk, or compliance and then triggering actions such as email, Jira tickets, or HTTP requests. That changes the control point from periodic review to event-driven handling. In practice, the value is not speed alone but the ability to apply consistent policy at the moment an unmanaged app enters the governance queue.

Practical implication: Define clear classification rules for discovered apps so automated actions reflect policy rather than just operational convenience.

Event-based onboarding and offboarding execution

The release also allows onboarding and offboarding workflows to run before, on, or after a key date, at an exact time, and in response to webhooks such as approval events or security detections. This is important because lifecycle control fails when the trigger is too coarse or too late. By aligning workflow execution with the actual business event, teams reduce missed deprovisioning, delayed provisioning, and manual exception handling. The model is still workflow automation, but with tighter timing and stronger linkage to authoritative signals.

Practical implication: Tie lifecycle automation to approved events and explicit execution timing so access changes happen when the business condition changes.

NHI Mgmt Group analysis

Workflow timing is now a governance control, not an implementation detail. When onboarding, offboarding, and licence optimisation can run before, on, after, or at a precise time, the control surface shifts from review cadence to event alignment. That matters because governance failures in SaaS often come from delayed action rather than absent policy. Practitioners should treat execution timing as part of access governance design, not as a convenience setting.

Discovered apps create a governance queue that must be classified before it can be trusted. The release extends automation to apps that exist in the environment but have not yet been brought under formal management. That is a useful operational pattern, but it also exposes a common assumption: discovery alone is not governance. Teams need a repeatable way to distinguish visibility from authorised control, especially where app usage, compliance state, and ownership do not align.

Shadow users and underutilised licences are lifecycle problems, not just cost problems. The Action Centre surfaces items such as resolving shadow accounts, removing underused licences, and classifying apps, which shows how closely SaaS hygiene and identity governance now overlap. Once these actions sit in a single prioritised queue, the practical challenge becomes decision discipline. Teams should expect governance debt to show up first as operational backlog, then as access risk.

SaaS governance is converging with device and workflow governance into one operating model. The unified device view across multiple MDM platforms shows that identity decisions increasingly depend on endpoint and asset context. That convergence is important because offboarding, compliance, and application access are no longer separable workstreams in most enterprises. Practitioners should design controls around the connected asset lifecycle, not around isolated admin consoles.

Runtime governance gap: The article points to a common failure mode where discovered apps and workflow triggers exist before a formal governance state does. That gap matters because organisations often assume a system can be made safe later through review, when in practice the first moments of use determine whether access, classification, and accountability are captured. Practitioners should redesign for governance at first sight, not after the fact.

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.
• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

SaaS governance is moving toward event-driven control, where discovery, classification, and lifecycle actions happen in the same operational flow rather than as separate processes. That matters because the value is not merely efficiency; it is reducing the time between unmanaged exposure and governed response.

Runtime governance gap: When discovered apps and shadow users enter the environment before they are classified, the organisation is already behind. Teams that still depend on periodic review alone will continue to miss the first moment when access, ownership, and compliance state diverge.

This release also reinforces a broader identity lesson: lifecycle control fails when visibility, ownership, and execution sit in different tools. The practical response is to design SaaS governance around authoritative events and bounded actions, not around after-the-fact cleanup.

For practitioners

• Consolidate SaaS, device, and license evidence Build a single operating view that links app discovery, license usage, security context, and device ownership before decisions are routed to remediation. This reduces the chance that offboarding or rationalisation happens without complete context.
• Classify discovered apps before automation fires Require a policy decision on usage, risk, or compliance status before discovered-app workflows are allowed to trigger tickets, messages, or API actions. This keeps automation aligned to governance rather than discovery noise.
• Prioritise shadow accounts and stale entitlements Use the action queue to separate high-risk access problems from low-value administrative work, then remove dormant accounts and unused licences through the same governance process.
• Tie offboarding to authoritative event triggers Run offboarding and access revocation from approved lifecycle events, security detections, or ticket approvals instead of relying only on periodic review cycles or manual follow-up.
• Apply role-based access to governance reporting Limit who can export or inspect SaaS governance reports so access data, device inventory, and remediation queues are visible only to the teams that need them.

Key takeaways

• SaaS governance weakens when discovery, classification, and action sit in separate systems.
• The release highlights the operational value of prioritising shadow accounts, stale licences, and unmanaged apps in one queue.
• Teams should anchor automation to authorised lifecycle events so faster execution also means tighter control.

Key terms

• SaaS Lifecycle Governance: SaaS lifecycle governance is the set of controls that manage applications from onboarding through access assignment, renewal, and decommissioning. It matters because the security value of SaaS management depends on whether the organisation can prove ownership, revoke access, and retire unused tools on demand.
• Shadow User: A shadow user is an account that exists outside the organisation's normal IT or IAM control plane. These accounts often surface after mergers, app sprawl, manual provisioning, or delegated admin use, and they matter because they can bypass standard lifecycle review and revocation processes.
• Workflow Trigger: A workflow trigger is the event or condition that starts or advances an automated process. In digital agreements, it matters because the trigger can function like a policy decision point, determining whether a signing action occurs and which downstream systems receive the document or status update.
• Tech Rationalization: Tech rationalization is the structured review of people, process, and technology to remove overlap, close real gaps, and improve how security controls work together. In practice, it turns tool sprawl into a governance exercise focused on measurable coverage and ownership.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.