Issue and Revoke System Access by Workflow: No Orphan Accounts

A new engineer joins on a Monday morning. By lunch she needs email, the drawing archive, the inventory system, and the expense tool. The IT lead opens a ticket, sends a chat to the manager, waits, copies the group list from the person who sat in that seat before, and manually adds her to four systems. Six months later she transfers departments, and her old access quietly stays. Two years after that she resigns and walks out. Nobody removes her accounts for weeks, sometimes months. One of those dormant logins is exactly the kind of credential that ends up in a breach report.

This is not a rare edge case. Orphan accounts, logins that belong to people who have already left or changed roles, are repeatedly named as one of the most common sources of unauthorized access in internal-control and security reviews. The cause is almost never malice. It is that granting access is ad hoc, ungoverned, and disconnected from the act of leaving. A core business system with a request-and-approve workflow fixes the root, not just the symptom.

Why Manual Provisioning Fails Audits

Account creation looks like a simple IT task. In reality it is an internal-control decision with three parts that paper and chat cannot hold together.

First, segregation of duties. A new starter should not receive access because one tired IT person clicked a template. The request should come from the hiring manager, be checked against a role definition, and be approved by someone accountable for that system. When the request, the approval, and the grant all live in different places, segregation of duties collapses into whatever is fastest on the day.

Second, the audit trail. When a reviewer asks who authorized a former employee to see the customer master, the answer cannot be a forwarded email from eighteen months ago. Internal control frameworks, including those Japanese listed companies answer to under J-SOX, want a frozen record of what was requested, who approved it, when it took effect, and what was granted. Paper and spreadsheets do not survive that question.

Third, the exit. The moment someone leaves, their access should be reviewed and removed. But leavers do not always pass through IT cleanly. A resignation letter lands in HR, the final payroll runs, and the accounts sit forgotten in a system nobody owns. The longer an orphan account lives, the larger the risk it becomes a backdoor, a credential-stuffing victim, or a compliance finding. The cost is measured in the one incident you cannot undo.

The shared flaw is that granting access has no governed request-and-approve trail. There is no single place where a request flows through manager and IT approval before access is granted, and no scheduled point where leaver access is removed.

What a Governed Access Workflow Actually Looks Like

The fix is not another standalone identity tool bolted on. It is an approval workflow inside the same ERP that already runs expenses, purchase orders, and leave. Here is what is genuinely built today and what is honestly still on the roadmap.

One request, routed by role and condition

An access request starts as a single structured form. The hiring manager picks the system, the role or group, and the business reason. The form can surface different fields per system, so a request for the drawing archive asks for a project tag while a request for finance asks for a cost center. This is the same dynamic-form capability the expense and leave workflows already use, applied to access.

The moment the request is submitted, it flows through a configurable approval route. Crucially, that routing is built and live today. The request travels to the requester's own manager automatically, because the workflow engine resolves the manager from the requester rather than a hardcoded name. It then routes to IT for the technical check and to a system owner for the business sign-off. Routing can branch by condition: a standard role goes to one approver, a privileged role goes to a second approver or a committee. Amount-style thresholds work here too, not for money but for sensitivity, so a high-privilege grant demands more eyes than a read-only one.

This conditional, role-aware routing is the part most companies get wrong with email. They write a rulebook that says administrator access needs two approvals, then in practice the first person clicks approve. A workflow engine enforces the rulebook every time, because the request cannot complete until the configured approvers decide.

See exactly where every request is stuck

Because every request lives in the workflow, you can see the state of every access grant in flight. Which is waiting on the line manager, which is in the IT queue, which came back for more detail. There is no chasing people down the corridor and no guessing whether the new hire will have what she needs on day one. Stakeholders who need to follow a request without being approvers, an IT lead tracking onboarding volume, can watch the request move without disrupting the approval chain.

A frozen snapshot of what was approved

When the request is approved, the system records a frozen snapshot of exactly what was decided: the system, the role, the requester, the approvers, the timestamps. This is the audit trail that answers the reviewer's question without anyone rebuilding history from memory. It is the same snapshot discipline that protects expense and purchase-order approvals today, extended to access.

Safe delegation when an approver travels

Approvals do not freeze when a manager is on the road. The engine supports safe delegation so a traveling manager can hand the queue to a deputy, with mandatory re-approval for higher-risk items. Access requests do not stall for a week because one person is at a customer site, which is exactly the delay that tempts people to bypass the process.

Being Honest About What Writes Back Automatically

Here is the boundary every buyer should ask about, stated plainly.

The request-and-approve control is built and live today. A manager requests access, the workflow routes it through the right approvers by role and condition, the decision and its full context are captured as a frozen audit snapshot, and the state of every request is visible while it moves. That is a real governance layer over who can ask for access and who must sign off.

What is on the roadmap, and not yet built, is the automatic writeback into the target systems. Automatically creating the account in the email directory, the drawing archive, or the inventory system the moment approval completes, and automatically revoking or expiring it on a scheduled date or at a leaver event, is work that is coming, not finished. The honest framing: the request-and-approve control is live now, and automatic provisioning plus scheduled revocation against your access systems is the next step. Anyone who claims their approval button silently provisions every downstream system today is overselling.

Even without the writeback, the value is concrete. Today the gap is not usually that IT cannot create an account. It is that nobody can prove who authorized it, nobody knows when it should expire, and nobody owns removing it. The workflow closes the proof, the ownership, and the scheduling. The final automated step into each target system is a contained piece of work once governance is in place, and it is what the roadmap covers.

A Scenario: The Precision Parts Maker in Shizuoka

Consider a precision parts manufacturer in Shizuoka, about 280 staff, supplying automotive and industrial-machinery OEMs from a head office, a factory, and a sales branch. Their IT team is small. Onboarding is constant because the factory runs shifts, and transfers between the engineering office and the production floor are common.

In the old flow, a new technician's access was copied from the previous person in that seat. Privilege accumulated over transfers because nobody subtracted what was no longer needed. When a senior engineer retired after thirty years, his accounts, including administrator rights on the drawing archive, stayed live for two months because his resignation passed through HR and payroll but never reached deprovisioning. During an internal-control review that quarter, the finding was blunt: the company could not produce a clean record of who had approved what access, nor prove leaver access had been removed on time.

In the governed flow, every access grant starts as a request in the workflow. The line manager submits it, the request routes automatically to the right approvers based on the role, and the decision is frozen with its full context. A privileged grant demands a second approver by condition, so administrator rights never depend on a single click. IT can see exactly which requests are pending and plan provisioning to land on the start date.

When someone transfers, the workflow handles the change as a new request, so access tied to the old role is reviewed rather than carried silently forward. When someone leaves, the offboarding request moves through the same trail, so the revocation of access is a governed, recorded event instead of a hope. The next year's review finds a frozen snapshot for every grant and a clean record for every exit. The orphan-account finding does not come back.

The estimated saving in the ROI model for a 280-person maker is modest in raw hours, around 167 hours a year from cutting manual coordination per request. The real value is the risk that does not happen: the retired engineer's dormant admin login is no longer sitting open for two months. That single avoided incident is worth far more than the hours saved.

Why This Belongs in the ERP, Not Beside It

The temptation is to buy a separate identity tool and treat access as a pure IT problem. That is how orphan accounts come back. Access is an approval decision like any other, and it belongs in the system that already holds the audit discipline for expenses, purchases, and leave.

When the access workflow lives in the ERP, three things line up. The approval route reuses the same manager-resolution as expense approvals, so reorganizations do not break routing. The audit snapshot uses the same frozen-record discipline as the rest of internal control, so a reviewer sees one consistent trail. And the leaver event starts in HR and reaches IT as a governed request rather than a rumor.

There is also a broader security payoff. Once access grants are governed requests, the same pattern extends to privilege escalation, temporary admin rights, and data-export approvals. Each is a decision that today happens over chat, and each is a finding waiting for the next audit.

Common Questions, Answered Honestly

Does this automatically remove accounts when someone leaves?

The offboarding request flows through the same governed approval trail, so revocation becomes a recorded, owned event with a clean audit snapshot. The automatic writeback that removes the account inside each target system on a scheduled date is on the roadmap, not yet built. The control and the record are live today; the final automated step into your access systems is coming.

Can we require two approvers for administrator access?

Yes. A standard role routes to one approver, while a privileged grant routes to a second approver or a committee by condition. The rule is enforced every time because the request cannot complete until the configured approvers decide. That is built and live.

What happens when an approver is traveling?

The workflow supports safe delegation, so a traveling manager hands the queue to a deputy, with mandatory re-approval for higher-risk items. Access requests do not stall because one person is away.

Will this replace our existing identity store?

No. The workflow governs the request and the decision and records the snapshot. The connection from an approved request into your existing directory is the writeback step the roadmap covers. The point is to put a governed, auditable control in front of provisioning, not to rip out what works.

Key Takeaway

Orphan accounts are not an IT accident. They are the predictable result of granting access without a governed request-and-approve trail. A core business system with a configurable workflow fixes the root cause: every access grant starts as a request, routes to the right approvers by role and condition, and is captured as a frozen audit snapshot. Automatic provisioning and scheduled revocation into your target systems are the next step on the roadmap. The control and the record are live today, and that is what stops the next dormant login from sitting open.

Get Started With Kikan System

If leaver access and ungoverned privilege grants keep showing up in your reviews, look at Kikan System. The request-and-approve workflow routes access requests through the right approvers by role and condition, freezes every decision as an audit snapshot, and keeps provisioning visible while it moves. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.