Identity, Roles, and Least Privilege
Who controls each critical account and can another authorised person recover the service during an incident? Use established identity mechanisms, enforce resource-level permissions on every protected operation, start access narrow, and review privileged accounts regularly.
What You Will Be Able to Decide
- Explain identity, roles, and least privilege in product and business terms.
- Apply this decision: Use established identity mechanisms, enforce resource-level permissions on every protected operation, start access narrow, and review privileged accounts regularly.
- Recognise this material risk: valid login or a broad role is treated as permission to access data belonging to another user or company.
- Use this review: Exercise contractor offboarding, secret rotation, backup restore, and the first incident handoff for the customer portal.
A founder is clarifying who controls the product and how the company will respond when something goes wrong. This lesson gives you a concrete question to take into a build brief, proposal review, or product decision.
Who controls each critical account and can another authorised person recover the service during an incident? The course example is A small team's customer portal with contractors and external integrations; use it to decide what evidence would justify the choice before a builder implements it.
What Does Identity, Roles, and Least Privilege Mean for Your Product?
A founder is clarifying who controls the product and how the company will respond when something goes wrong.
Use the illustrative service for this course (A small team's customer portal with contractors and external integrations) to make the choice concrete. Who controls each critical account and can another authorised person recover the service during an incident?
Technical term
Identity, Roles, and Least Privilege
Authentication proves an identity; authorisation evaluates whether that identity may access a particular action or resource; least privilege keeps the resulting role as narrow as practical.
How Should a Founder Use Identity, Roles, and Least Privilege?
For a small team's customer portal with contractors and external integrations, ask what would happen if valid login or a broad role is treated as permission to access data belonging to another user or company.
For this decision, the useful standard is that access, ownership, recovery, and response responsibilities are explicit and can be exercised without one individual.
- Decision: Use established identity mechanisms, enforce resource-level permissions on every protected operation, start access narrow, and review privileged accounts regularly.
- Evidence to request: show that access, ownership, recovery, and response responsibilities are explicit and can be exercised without one individual.
- Owner: name who will respond if valid login or a broad role is treated as permission to access data belonging to another user or company.
- Record the result in the security, ownership, and handover record.
- Practical review: Exercise contractor offboarding, secret rotation, backup restore, and the first incident handoff for the customer portal.
How Do You Choose an Approach to Identity, Roles, and Least Privilege?
Who controls each critical account and can another authorised person recover the service during an incident? Use established identity mechanisms, enforce resource-level permissions on every protected operation, start access narrow, and review privileged accounts regularly.
The risk is that valid login or a broad role is treated as permission to access data belonging to another user or company. Compare a simpler option with the proposed one, including who will operate either choice.
- Describe the user or business outcome that must be protected.
- Identify the most credible failure and its consequence.
- Compare the simplest adequate approach with one realistic alternative.
- Set a review point for when the decision may need to change.
What Evidence Should You Accept for Identity, Roles, and Least Privilege?
What Warning Signs Should You Look For?
- The proposal does not address this risk: valid login or a broad role is treated as permission to access data belonging to another user or company.
- Nobody can show whether access, ownership, recovery, and response responsibilities are explicit and can be exercised without one individual.
- The decision has no named owner or review point.
What Should You Ask a Consultant?
- What changes for the user if we choose this approach to identity, roles, and least privilege?
- How have we reduced or accepted this risk: valid login or a broad role is treated as permission to access data belonging to another user or company.
- Can you demonstrate that access, ownership, recovery, and response responsibilities are explicit and can be exercised without one individual?
- Who owns the result, and when will we reconsider it?
Key takeaway
Key Takeaway
Use established identity mechanisms, enforce resource-level permissions on every protected operation, start access narrow, and review privileged accounts regularly. Ask for evidence against the specific risk: valid login or a broad role is treated as permission to access data belonging to another user or company.