Video summary

Designing an IAM Strategy for your Engineering Platform -

Main summary

Key takeaways

Technology

Overview

Henry (developer & architect from the Netherlands) shares a case-study style IAM strategy based on lessons learned from real customers over ~2.5 years (four different customers).

The talk focuses on moving from complex, hard-to-change access models toward a design that:

  • Improves engineer productivity
  • Remains audit/compliance-friendly
  • Starts with ISO 27001 requirements

Core problem / challenge

IAM often forces a trade-off between:

  1. Engineers need to start working on day one (fast onboarding of access).
  2. Organizations must ensure people only have the access they need (governance, review, audit, approvals).

Failure modes by organization size

Large enterprises (e.g., ~10,000 engineers)

  • Access via Entra ID groups / group nesting becomes extremely complex.
  • Group membership grows over time; permissions aren’t effectively “refueled” (re-evaluated).
  • Access reviews may exist, but effective permissions are hard to predict due to nesting and rarely-reviewed structures.
  • Refactoring stalls because changes to authorization structures create unintended side effects (“it grows over time”).

Small organizations (e.g., ~10 engineers)

  • Everything is reactive: “give Henry database access because we trust him.”
  • Little to no governance, review, or auditing—access tends to become permanent.

Key design principles (what the system must achieve)

  • Engineer productivity: access should be easy to request and obtain.
  • Provability / auditability: explain who has what access and why.
  • Approval responsibility
    • Access should be decided by the asset/product owner (or responsible manager), not a generic centralized admin.
    • The speaker frames this as an organizational/business-risk decision, not “admin-only” decision-making.
  • The solution must be:
    • Explainable to engineers
    • Extensible
    • Compliant, starting with ISO 27001

The “three ingredients” solution (Microsoft-focused)

  1. Microsoft Entra ID Privileged Identity Management (PIM)
  2. Microsoft Entra ID Access Packages
  3. A custom design layer: a role × product scoped access model

The speaker notes this can be adapted to other IAM stacks, but the demo/implementation is in Entra ID, Azure DevOps, and Azure.

Ingredient 1: PIM recap (security pattern)

With PIM, users are typically eligible for a privileged role, but must activate it to gain the privileges.

Benefits emphasized

  • Reduced blast radius: privileges aren’t automatically active if credentials are misused.
  • Additional activation conditions, such as:
    • MFA
    • Device compliance
    • Authentication context labels

Demo highlights

  • Protecting roles like Global Administrator
  • Enforcing MFA for activation (MFA cannot be disabled in the demo context)
  • Using authentication context labels with conditional access to require conditions like:
    • Compliant device
    • Corporate network

Approval flow

  • Requests become pending approval
  • Standing admins can approve requests and include a reason for auditing

Whether approvals can be required 24/7 is a business decision (risk vs. speed), not purely technical.

Ingredient 2: Access Packages (governed bundles of authorizations)

Access Packages are defined as a named bundle of authorizations plus governance about using them.

What Access Packages can include

They can grant things like:

  • Group membership
  • Group ownership
  • App roles / app permissions
  • (Speaker includes SharePoint in examples)
  • Access packages can include Entra ID roles (noted as a later update)

Governance includes

  • Request rules (e.g., ticket number, manager approval, approval by members of a group)
  • Approval rules and stages (speaker advises against too many)
  • Lifecycle rules (e.g., requiring periodic access reviews)
  • Expiration/recertification patterns
    • Speaker prefers access review/refueling rather than “auto-expiring” blindly

Licensing notes

  • Access Packages require Entra ID P2 (as mentioned by the speaker).
  • Some capabilities require Entra ID Governance licensing; otherwise it may still work indirectly via groups.

Demo highlights

  • Creating an access package (name/description)
  • Adding resources (group membership, app/API permissions)
  • Configuring self-service requests via myaccess.microsoft.com, including approvals/denials

Ingredient 3 (main architecture): role × product scoped access packages

This is the core “design” effort.

Organizational constructs used

  • Every person should have a clearly defined role, e.g.:
    • Product Owner
    • Engineer (with a critical distinction—see below)
    • Stakeholder / others (want/need visibility but not change)

Engineer split: non-production vs production

The design separates for engineers:

  • Production work / exceptional privileges (when something is broken and needs manual intervention)
  • Non-production day-to-day work

Claim: you shouldn’t be both simultaneously; privilege is temporary/conditional.

Product scoping / “long-lived assets”

  • Access governance is aligned to products (long-lived software/IT products), not ad-hoc projects.
  • The design proposes one access package per combination of role and product.

Authorizations mapped using Entra ID groups

A deliberate pattern:

  • Create Entra ID groups named by:
    • Product scope
    • Target system (e.g., Azure DevOps vs Azure)
    • Authorization type
  • When an access package is approved, it grants group membership.
  • Target systems use those groups to enforce permissions.

Example flow: “All Products Administrator”

  1. Approved access package → user becomes member of Entra ID groups
  2. Entra ID: global administrator role assignment (often eligible via PIM)
  3. Azure DevOps: project collection administrator permissions via group membership
  4. Azure: root management group owner permissions via group membership
  5. Also uses a bootstrap approver/reviewer group:
    • People responsible for approvals are included in an “approver” group
    • Product owners can delegate review/approval for their product

Mapping the role model into real engineering permissions

For each product, different access packages map to permissions such as:

  • Product Owner

    • Approval rights
    • Often needs cost visibility (speaker notes product owners “always want to know what stuff costs”)

  • Stakeholder

    • Typically read-only (visibility into repositories/work items/pipelines but no change rights)

  • Engineer (non-production)

    • More permissive in non-production (e.g., contributor on appropriate scopes)

  • Engineer (production)

    • Owner-level permissions on production subscriptions
    • Framed as deliberate and time-bound/exceptional
    • Speaker argues production owner rights should be rare—only when “stuff hits the fan,” because owner rights are risky

Key Azure DevOps / Azure assumptions in the design

  • Prefer one team project in Azure DevOps to reduce cross-project complexity.
  • Prefer subscription per workload/deployment (a “subscription democratization” model).
  • Use contributor vs owner carefully:
    • Non-production engineers get contributor (can change, but not grant access freely).
    • Production engineers are given owner to enable emergency remediation when permission breaks occur.

Results / experiences (what worked and what didn’t)

Positive outcomes

  • Product owners decide access (key governance/pet peeve solved).
  • Engineer onboarding speed:
    • New engineers can request multiple access packages quickly
    • Setup can happen within minutes
  • Auditability and audit record quality:
    • Decisions are tied to access packages and PIM flows
    • Includes recorded reasons
  • Privilege escalation is controlled and still requires justification.
  • Access reviews are enforced via tooling (replacing manual Excel-based workflows).

Issues / limitations observed

  • Review results aren’t immediate

    • During the review window, revocations may not apply until the end
    • Example: access that needed revocation wasn’t effective yet; PO “paused” extension instead of recognizing timing effects

  • Multiple reviewers confusion

    • A deputy PO may take over during absences
    • The original PO may not later see what happened

  • App registration access not fully supported as a resource

    • Some access types (e.g., app registrations) still require manual steps due to inability to assign group as owner

  • Effective-time revocation delay

    • Revocations may not apply instantly
    • Requires additional operational time to fully remove access

Main speakers / sources (as requested)

  • Main speaker: Henry
    • Developer & architect from the Netherlands
    • Presenter and identity/IAM strategist for engineering platforms
  • Primary referenced product/features: Microsoft Entra ID
    • Specifically Privileged Identity Management (PIM) and Access Packages
    • Integrated into Azure and Azure DevOps

Original video