Pilot Onboarding

AccessLedger is currently introduced through a founder-led pilot. This checklist is meant to get a new tenant from empty workspace to a usable break-glass workflow quickly without pretending the product is already a fully packaged self-serve SaaS.

Before you start

• Confirm the pilot owner and the approvers who will review emergency access requests.
• Identify the first small batch of privileged credentials to register.
• Decide which vault, password manager, or documented storage process remains the system of record for the actual secret value.
• Decide which break-glass events or audit requests you want the pilot to prove out.

Initial setup checklist

1. Create the organization workspace and first admin user.
2. Add a small credential inventory with accurate storage locations and risk levels.
3. Assign approvers, auditors, and requesters.
4. Configure notification settings so request and reminder emails go to the right people.
5. If the tenant will use SSO, configure the OIDC issuer, client ID, and client secret under Settings → SSO before assigning users to federated sign-in.
6. Verify one end-to-end request flow: request, approve, expiry, closeout, and audit review.

SSO rollout and recovery guidance

• Start in optional mode so existing local sign-in remains available while the tenant validates issuer settings and user assignment.
• Keep at least one active local admin account as a recovery path before switching to enforced mode.
• Only assign oidc sign-in to pre-provisioned users whose email address already matches the tenant IdP record.
• Use enforced mode only after a real login succeeds and the tenant understands that non-admin local password flows are intentionally blocked.
• Do not convert or deactivate the last local admin recovery account while SSO is enforced.

Suggested pilot policy defaults

• Start with a narrow set of high-risk credentials instead of importing everything at once.
• Use short approval durations and require closure notes after each approved request.
• Pick one or two approvers who can participate consistently during the pilot period.
• Review rotation expectations up front so “credential rotated” and follow-up notes stay meaningful.

First workflow walkthrough

1. Register a credential and record its storage location.
2. Submit an emergency access request with a clear reason and incident reference.
3. Approve the request with a short duration.
4. Let the requester close the request with post-use notes and rotation follow-up.
5. Review the resulting audit events and export the audit log for discussion.

Exit criteria for a useful pilot

• The team can explain who requested access, who approved it, when it expired, and how it was closed.
• Approvers and requesters understand the workflow well enough to repeat it without guided hand-holding.
• The exported evidence is useful for internal review or external audit preparation.
• The customer can identify whether the next bottleneck is identity, telemetry, or import/integration friction.