What to Look For in Employee Onboarding Software in 2026

Your HR team probably has onboarding down. Offers get e-signed, tax forms get filed, and a welcome email with the training plan lands before anyone's first morning. Then day one starts, and IT spends the week working tickets for access the new hire should already have.

Employee onboarding software automates the work between a signed offer and a productive first week, from paperwork and training to the accounts and access a new hire needs. Most onboarding software handles the HR half of employee onboarding well, and if that's the half you're buying for, your HRIS's onboarding module is probably enough.

The access half is harder, because it fails in two directions at once. New hires wait for the access they need, and they hold access nobody meant to give them. The seven features below are where tools differ most on that half, and each one helps you find out, before you sign, which tool gets your next hire working on day one.

Birthright policies built from what each role uses

Look for software that builds a new hire's default access from what people in the same role use, and shows you the evidence before it grants anything. Birthright access is the default set of apps and permissions everyone in a role gets without asking, and it's where a new hire's access starts. When that default is thin, the new hire waits, and the usual shortcut of copying a teammate's account hands them years of someone else's grants.

This is the first decision any employee onboarding software makes for you, whether or not it shows you the decision. A tool that copies a template or a teammate has still decided, and it has decided to give the new hire whatever that source happened to hold. The better pattern is default access built from policy before the first sign-in, which is where any plan for how to automate HR onboarding and offboarding should start.

A February 2026 audit from VA's Office of Inspector General shows what happens when nobody examines that decision. On VA's new financial and acquisition platform, default access was set by organization and position before each deployment wave went live. One user asked for a single view-only role and was granted three more by default, including one that opens detailed acquisition records that may contain sensitive information. Access wasn't limited as required for any of the 20 users the auditors sampled.

The tool approvers used didn't show everything a person held in the platform, and VA's own response to the audit says default access isn't included in its access review. Of the 129 roles the sampled users held, 79 were never checked in VA's quality reviews. The best user access review software pulls default grants into every cycle, which is the step VA's process skipped. The broadest access anyone held was the access nobody had looked at.

So ask for default access built from HR attributes plus what people in the role hold and use, granted at the permission level (the CRM's reporting role, say, where a cruder tool hands over the whole app). It should arrive as a proposal with its evidence attached, show up in access reviews like any other access, and change when usage changes.

The proposal should arrive with its evidence, and that's how Albus works: it ingests HRIS data, app assignments, and usage logs, proposes role-based and attribute-based policies, and explains why each role exists. Your team tunes assumptions instead of rubber-stamping them. Our own IT team runs onboarding on those policies, with Albus helping recommend birthright bundles and flag unnecessary access. New hires get their birthright apps on day one, as Prema Nagarajan, our Director of IT, describes in how we run IT on Lumos.

In every demo, ask the vendor to propose default access for one of your departments from your own data, then point at any grant and ask what usage put it there. A vendor that can't answer is guessing on your behalf.

Provisioning that writes accounts and entitlements into every app

The right tool creates a new hire's accounts and sets their permissions inside each app from the HR record, before the first sign-in. CIS Controls v8.1 Safeguard 6.1 asks for a documented process, preferably automated, for granting access when someone is hired or changes roles. It sits in Implementation Group 1, the baseline CIS sets for companies of any size.

Plenty of products sold as an employee onboarding platform meet the letter of that by emailing IT. What's sold as IT onboarding software often stops at opening a ticket for each app, which moves the work around without doing it. Real employee onboarding automation starts where that ticket would have, at the HR record. Setting permissions inside each app is the job of identity governance software, and the ladder below shows how far short of it most onboarding tools stop.

At Code42, employees made about 100 access requests a week. IT could take anywhere from 4 hours to a couple of days to see a ticket, find the right app admin, and provision access for that one request. Lumos now handles that work within minutes. A new hire's day-one tickets wait in the same queue as everyone else's, so a ticket per app costs you their first week as well as IT's time.

The ladder below rates how far a tool gets on its own when a new hire lands in the HRIS. Rate each app separately, because most tools sit on different rungs for different apps.

‍

Automated user provisioning that stops at step 3 creates accounts with whatever default role each app assigns, which is rarely the one the job needs. When a start date hits your HRIS, Lifecycle Management provisions the identity provider account, email, and role-based default access with no ticket. Lumos integrations then set roles, groups, and project levels inside the apps they connect to. They reach apps outside your identity provider through a direct API or browser agents, so the first sign-in lands in working access.

Before any demo, rate your current tooling on the ladder for your 20 most-used apps, then ask each vendor to rate itself against the same list. The sensitive apps sitting at step 1 today are your business case.

License controls that match each new hire's seats to what they use

A new hire's day-one apps are also seats you pay for, so the tool that grants them has to know which seat the job needs and notice when one goes unused. That's why step 4 on the ladder includes license type, since the tier is an access decision too.

Copied defaults land on whatever tier the template held, so a new hire's seat can come at a teammate's tier whether or not the job needs it. A new hire who never opens an app in their first month still holds a paid license, and nobody tends to notice until the renewal. Short projects leak the same way, when someone needs a tool for a month and keeps the seat for a year.

Ask for last-used data on each app, time-based seats for short projects, and unused seats returned to a shared pool. Where an app exposes license types, ask for the tier to be set by policy at the moment of the grant as well.

At Checkr, seats now follow use instead of headcount. Lumos helped the team see when each employee last used an app. For apps that are cagey about usage, like a diagramming tool requested for a month-long project, employees request time-based access. Bradon Lewis, Checkr's IT Operations Manager, describes the result as "a dynamic license pool that constantly adjusts."

The tier is the one part of default access that arrives as an invoice, which makes it the easiest part to put a number on. Count the premium seats last quarter's hires never opened in their first month, in your most expensive apps, and you'll have that number before any vendor's pricing call.

One tracker for every new hire's automated and manual steps

Some onboarding steps will always need a person, like an app at step 0 or 1 on the ladder, a sign-off, or a hardware order. Your tool has to show those steps next to the automated ones, because a manual step with no owner and no due date is how a start date slips. Test and demo environments are often that kind of step, where an admin adds each new hire by hand once someone tells them a person started.

Most employee onboarding tools track forms and training, while the steps that block day one live in the access work. An HR checklist can show the welcome email sent while the CRM seat sits in an admin's inbox. Every manual step needs an owner, a due date tied to the start date, an automatic reminder, and a status IT can read without asking anyone.

The fix is one view for both kinds of step. From automated steps to manual tasks, Lumos gives IT and security teams one place to track onboarding progress. That view is where a slipping step shows up days before the start date, while there's still time to fix it.

The week before your next start date, list every step in your employee onboarding process that isn't automated for that hire, with an owner and a due date. If that list takes more than five minutes to produce, that's the feature you're shopping for.

Approval routing that sends access requests straight to app owners

Whatever default access doesn't cover belongs with the app's owner, with reminders and a backup approver, and out of IT's queue. In the first week, each new hire asks for something default access missed. In a ticket model, IT reads the request, works out who owns the app, and relays it, then waits to provision. The waiting is in the relay.

New hire onboarding software that sends every request through IT has rebuilt the queue it was bought to remove. A manager knows whether the new hire needs an app, and the app's owner knows what each permission inside it opens. So ask for a named owner on each app and routing by sensitivity, with the manager approving routine requests and the app owner approving sensitive ones.

Ask, too, for reminders, escalation to a fallback approver, expiry for requests nobody answers, and provisioning the moment someone approves. Each one closes a place where a request can sit unanswered through a new hire's first weekend.

Lumos sends requests outside default access straight to the app's designated owners or approvers by policy. If one sits in Slack too long, the bot reminds the approver, and fallback approvers or auto-expiry rules keep it from sitting in limbo. At Chegg, IT took itself out of the middle between the people requesting apps and the people approving them. Managers and business units now handle approvals across more than 2,500 people, on approval paths that keep Chegg SOX compliant as a public company.

In the pilot, have a test hire request two apps outside default access on day one, one routine and one sensitive, and time each from request to working access. Write down who had to act, because if IT is on every line, the routing isn't there yet.

Joiner workflows for contractors, interns, and temporary workers

Contractors, interns, and temporary workers need joiner workflows with a sponsor and an end date from the first grant, because they're where onboarding tools most often break. Your HRIS lists employees, while contractors often live in vendor portals, contractor platforms, and spreadsheets, so their access arrives by ticket with no end date. Remote contractors add one more step, since online employee onboarding has to check their identity at activation like any other remote hire's.

Every joiner needs a source of record, a sponsor, and an end date set when the account is created. They should get the same default access policies and approval routing as employees, and their access should end on its own. Onboarding interns and seasonal hires who start together as a cohort, with one end date set at the first grant, is one of the employee onboarding best practices that keeps temporary access from drifting. The service accounts and AI agents a new hire sets up need the same three things, which is where an automated non-human identity lifecycle takes over.

The table below lists the joiners that break onboarding tools most often, with the question that exposes each one in a demo. Swap in your own hardest hires from the last year.

‍

The access an intern gets in June can end on the date you set in June, whether or not anyone remembers in August. Lumos supports time-bound lifecycle policies that provision and revoke access on defined schedules, including ahead of a start date, for temporary workers, on-call employees, and interns.

Demo scripts tend to skip every row in that table, which is why each one belongs in your pilot. Weight the rehire and conversion rows most heavily, since the platform that opens an account should also close it, the same test you'd put to employee offboarding software.

A recorded reason for every grant a new hire receives

Each account and permission a new hire receives needs to trace to a policy or a named approver, recorded at the moment it was granted. Under the AICPA's Trust Services Criteria, the criteria behind SOC 2, CC6.2 expects you to register and authorize new internal and external users before issuing credentials. Its points of focus describe credentials created on the authorization of the asset's owner or an authorized custodian, and "external" covers the contractors from the last section.

An auditor tests this by sampling new hires and asking, for each account, who authorized it and when. A grant that came from a copied template has no answer, and neither does a default grant nobody can trace back to a policy.

Tickets and spreadsheets make poor records, and the gaps show up as access nobody can explain. ChargePoint's IT team ran access requests and user access reviews by hand, through tickets and spreadsheets, and says the work was prone to human error and often left employees overprovisioned. Once reviews ran in Lumos, the team had one place to see which applications were overprovisioned.

The record should hold four things for each grant: which policy (and which version) or which approver, when it was granted, what changed, and where the evidence lives. Default grants count, and you should be able to export the whole record for any one person. That export is also the list a mature offboarding process works from when the person leaves.

That record is already written by the time an auditor asks. Lumos tracks every grant and revocation across your identity provider, your HRIS, and your SaaS, cloud, and on-premises apps with a full audit trail. Albus's auto-approvals in AppStore carry the same trail for every grant, denial, and expiration. Lumos user access review software then brings each grant back with its usage, prior decisions, and known exceptions, so access that made sense on day one gets checked again in month six.

Ask each vendor for the exact record they'd hand an auditor for one sampled new hire. Every grant on it, default grants included, should name a policy or a person.

Judge every vendor by the access it would give your next hire

Pick a role you're hiring for next quarter and hand it to each vendor on your shortlist. In a pilot on your own data, each one should show what that hire would hold at 9 a.m. on day one: the apps the role uses, at the right tier and permission level, and nothing copied from a teammate. Then ask for the record an auditor would pull for that hire, and buy the tool that can explain every grant on it.

Many tools demo well at step 2 or 3 on the ladder, where the accounts exist and the real permissions are still somebody's ticket. Default access is a decision, not a template.

Run that hire through Lumos, and day one goes the other way. Albus proposes the default access for the role from what people already in it use, and Lifecycle Management provisions it when the start date hits your HRIS. The new hire signs in to every connected app the role needs with the permissions already set, and none of a teammate's leftovers come along.

When they ask for something outside that default, the request goes straight to the app's owner or approver, with IT out of the relay. Every grant they hold carries a record your auditor can sample and your next access review can check. Book a demo and bring a real department's next hire to watch that hire's first day run end to end.

‍

‍