Many SSO implementations auto-provision: the first time someone successfully authenticates through the firm's identity provider, the application quietly creates a new account for them on the spot. Lekhya deliberately does not do this. Its SSO authenticates only existing members who already have an active membership in that firm — if someone isn't already invited, a successful login at the identity provider gets them nowhere. This is a conservative design choice made on purpose, not a missing feature.
What auto-provisioning actually does
Auto-provisioning (sometimes called just-in-time or JIT provisioning) is popular because it removes a step: instead of a firm admin explicitly inviting each person into a tool, anyone in the firm's identity-provider directory who successfully logs in gets an account created for them automatically, often with some default role. It's genuinely convenient for low-stakes internal tools — a wiki, an internal chat app, a scheduling tool — where the cost of an unintended account is low.
For an audit tool holding client financial data, workpapers, and engagement files, the calculation is different. The firm's identity-provider directory typically includes everyone with a company email — reception staff, interns, people in departments that have nothing to do with audit work. If logging in through SSO were enough to get an account provisioned, the effective access boundary for a highly sensitive tool would be 'does this person have a company email account,' which is a much wider boundary than any firm actually intends.
Why Lekhya chose the narrower path
- Being in the firm's identity-provider directory and being a vetted, invited member of a specific audit engagement are two different facts, and conflating them widens access further than most firms would choose if asked explicitly.
- An invite is an explicit, auditable action taken by someone at the firm with authority to grant access — a log entry exists for who added whom, and when.
- Auto-provisioning makes the identity provider's directory membership the real access boundary, even though nobody at the firm configured it to be that permissive on purpose — it's an accidental widening, not a deliberate decision.
- Removing someone from the firm's identity provider stops them authenticating either way, but with invite-only provisioning, there was never a path for the wrong person to get an account in the first place.
How we think about this
Successfully proving who you are to an identity provider answers 'are you who you claim to be.' It does not answer 'should you have an account in this specific audit tool.' Those are different questions, and Lekhya's SSO only ever answers the first one — the second is answered exclusively by an explicit invite from the firm, exactly as it would be for a password-based signup.
What this costs in convenience
The honest trade-off: a firm bringing on a new hire still has to explicitly invite them into Lekhya, separately from adding them to the firm's identity provider or email system. There's no moment where simply being added to the company directory is enough — someone with admin rights at the firm still has to take the extra step of inviting the new person into the tool before their first SSO login will do anything. For a firm onboarding staff in batches, that's one more item on the new-hire checklist, not zero items.
Common practice, not a requirement
Firms that pair SSO with a habit of inviting new staff into every active tool as part of day-one onboarding (rather than waiting until someone needs access to something specific) don't feel this cost much, because the invite step gets folded into a process they're already running.
What doesn't change
None of this touches authorization. Once someone is invited and successfully authenticates via SSO, what they can see is still determined entirely by their role and the engagements they've been added to — identical to how it works for a password login. The no-auto-provisioning rule is specifically about the membership boundary, not about access levels within the tool once membership exists.
Don't assume every audit or practice-management tool a firm uses behaves this way by default. Auto-provisioning is common enough that it's worth asking any vendor directly: does a successful SSO login create a new account automatically, or only authenticate someone already invited? The answer changes the real size of a firm's access boundary.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit workflow & automationSingle sign-on for audit firms: why it matters more at 80 engagements than at eightBelow a certain headcount, SSO is a convenience. Above it, it's the only realistic way offboarding actually happens on the day someone leaves.
- Internal audit & IFCUser access review audit procedure for financial systemsA signed-off access review spreadsheet is evidence someone looked at a list. Whether access was actually removed as a result is a separate fact the audit has to test.
- Internal audit & IFCTesting segregation of duties: a practical approachThe classic SoD conflicts, how to test for them in a small finance team where perfect separation is not realistic, and how to document the compensating controls that stand in.
- Audit data & extractsHandling client data securely during fieldworkPen-drive discipline, who can open the shared drive, and what happens to the client's data after sign-off: the practical hygiene that protects a firm handling someone else's accounting records.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.