An Identity Workshop Kit for Startup Incubators
Run a focused identity workshop for a Rajasthan startup cohort. Use an agenda, access exercises, review worksheet, and follow-up checklist.
Retrospective series date: 2026-09-30. This label describes the series order, not a historical publication.
A useful identity workshop should end with a decision each founder can act on. A broad presentation about security rarely produces that result.
This kit helps a Rajasthan incubator run a focused session. Teams leave with an account model, one access test, and a short action list.
Set the workshop outcome
Ask each startup to bring one customer journey. Examples include joining an organization, booking a service, or opening a private project.
The outcome is a reviewed access decision for that journey. The workshop does not certify the product's security.
Use synthetic users and records. Participants must not share production credentials, personal documents, or customer exports.
Prepare the cohort
Collect the product stage, framework, sign-in method, and one question from each team. Ask for a public diagram or a sanitized description.
Group teams by the decision they need to make. A prototype without accounts needs a different exercise from a product with several organizations.
Check accessibility, internet access, and whether participants can run their development environment.
Use this 90-minute agenda
Download the workshop agenda. Add a facilitator and completion result for each activity.
The duration is a suggested format, not a measured outcome.
| Time | Activity | Deliverable |
|---|---|---|
| 0–10 minutes | Explain the journey and actors | One sentence describing the task |
| 10–25 | Separate authentication from authorization | Actor and action table |
| 25–45 | Draw account and organization boundaries | Small access diagram |
| 45–65 | Run a denied-access test | Recorded expected and actual result |
| 65–80 | Review recovery and access removal | Two failure cases |
| 80–90 | Assign next actions | Owner and deadline for each task |
Keep teaching sections short. Reserve time for founders to show their actual decisions.
Exercise one: who can do what?
Ask each team to list three actors and three actions. Add one action each actor must not perform.
Do not accept “admin can do everything” without a review of the need. Separate support access from customer administration.
Use the multi-tenant guide when the application serves several organizations.
Exercise two: prove a denied request
Create two synthetic users. Give each access to a different private record.
Ask user A to request user B's record through the API. The server should deny the request.
Then remove user A's membership and repeat the original allowed request. Record whether the removal took effect.
The exercise is small enough to discuss. It also reveals whether the team relies on interface visibility as an access control.
Exercise three: review a lost account
Ask what happens when a user loses a device or email access. Identify who can approve recovery.
A founder should explain the evidence, escalation route, and audit record. If those decisions are missing, create an action rather than improvise a bypass.
Read the secure recovery guide for follow-up.
Copy the review worksheet
| Finding | Evidence | Owner | Due date | Retest |
|---|---|---|---|---|
| Missing access check | Sanitized request and result | Name | Date | Planned test |
| Shared administrator | Role inventory | Name | Date | Individual accounts |
| Unclear recovery | Current support route | Name | Date | Reviewed procedure |
Collect only the findings needed for follow-up. Do not retain participants' credentials or private datasets.
Contact the NamoID team
Incubator managers can discuss this format with NamoID. Our team may help scope an identity session, subject to fit and availability.
Contact NamoID in Slack with the cohort size, stage, frameworks, and proposed dates.
For formal support requests, use the partnership route. No institution referenced in this series is presented as a NamoID partner.