Single sign-on lets a firm's staff log into an audit tool using the same account and the same identity provider — Google Workspace, Microsoft Entra, Okta, or whatever the firm already runs — that controls every other application they use, instead of a separate password that only exists for that one tool. For a small firm this is a convenience. For a firm running enough staff and enough offices that someone leaves or changes role every month, it is the difference between access actually being revoked the day someone departs and access quietly persisting in a tool the IT team forgot existed.
The problem SSO actually solves
A firm with fifteen people and one office can track who has access to what by memory, or by a shared spreadsheet someone updates when they remember to. A firm with eighty engagements, several offices, and staff turnover at the normal rate for the profession cannot. The real failure mode isn't a weak password — it's a departed employee's account in some tool nobody thought to check during offboarding, because offboarding was a checklist item for the HR system and the email account, and the audit software login was a separate account nobody linked to either.
Common practice, not a requirement
Offboarding checklists that list applications by name eventually miss one, because the list has to be maintained by hand and grows every time the firm adopts a new tool. SSO turns offboarding into a single action — disable the account at the identity provider — that automatically reaches every connected application at once, including the ones the checklist forgot.
What SSO changes, and what it doesn't
| What SSO actually does | What it does not do |
|---|---|
| Centralises authentication at one identity provider | Does not change who can see which engagement — that's still role and membership |
| Makes offboarding a single action at the identity provider | Does not remove the need for a role-change process when someone's job changes |
| Lets the firm enforce its own password and MFA policy once, centrally | Does not substitute for the tool's own within-firm access control |
| Removes one more password for staff to manage and for IT to reset | Does not make the tool itself more or less secure against a direct attack |
A vendor that implies SSO is itself an access-control upgrade is overselling it. SSO changes how someone proves who they are; it does not change what they're allowed to do once they're in, which is still governed by whatever role and membership system the tool already has.
What to actually ask a vendor
- 01Which protocol, specificallyOIDC (OpenID Connect) is the modern standard most identity providers support out of the box. SAML is older and more firms running it have legacy reasons to. A vendor should be able to name which one they support rather than answering 'yes, SSO' without specifics.
- 02Does it auto-provision accounts, or only authenticate existing onesAuto-provisioning — creating a new account the first time someone logs in via SSO — is convenient, but it also means anyone in the firm's identity provider directory can get into the audit tool without anyone there explicitly granting them access. A tool that only authenticates existing, already-invited members is the more conservative default for a sensitive client-data application.
- 03What happens when the identity provider is unreachableIf the firm's own identity provider has an outage, does the audit tool fail closed (nobody can log in) or does it fall back to a password that most people haven't used in months and don't remember? Either answer is defensible; the vendor should have one.
- 04Is it per-firm, or does one firm's SSO configuration leak into another'sIn a multi-tenant product, each firm's identity provider configuration — issuer, client ID, client secret — should be stored and used independently, never shared across firms even accidentally.
When it genuinely doesn't matter yet
A firm of five with one office and staff who've been there for years has a real but small access-security surface. SSO is still a reasonable thing to have, but it is not the decision that will meaningfully change that firm's risk exposure. It starts to matter once the number of people who could plausibly have a stale account — because they left, because they changed firms-within-firms, because an office was onboarded and offboarded in the same year — stops being a number a partner can keep in their head.
How we think about this
Lekhya's single sign-on is OIDC against whatever identity provider a Firm-plan client already runs, authenticates only existing, already-invited members (it never auto-provisions an account), and changes nothing about what a logged-in member can see — that's still governed entirely by their role and engagement membership, exactly as it is for a password login.
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 & automationMulti-partner firm technology decisions: who needs to be in the roomA managing partner, an audit partner, and a quality-control partner are evaluating three different things when they look at the same software. Here's what each one actually cares about.
- Technology, data & AI in auditCybersecurity considerations for a CA firm handling client dataA CA firm's client folder is a more concentrated target than any single client's own systems — one firm holds financial data for dozens of companies in one place.
- Technology, data & AI in auditAudit software security questionnaire: a buyer's checklistThe questions a firm's own IT or compliance reviewer raises before sign-off, listed so they can be answered before the vendor call, not during it.
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.