Notifications
Clear all
Topic starter
06/06/2026 2:06 am
TL;DR: April updates add resource-scoped custom roles, a Groups API for organising memberships, self-serve email change with verification, and expanded IT contact handling across admin setup flows, according to WorkOS. For IAM teams, the governance story is less about convenience and more about tighter lifecycle control, clearer admin ownership, and cleaner permission boundaries.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern self-serve account changes without weakening identity assurance?
A: Use verified change flows, treat email changes as recovery events, and monitor for unusual mailbox or domain switches.
Q: When do scoped roles reduce risk, and when do they just add complexity?
A: Scoped roles reduce risk when the resource boundary matches how access is actually consumed and reviewed.
Q: What do IAM teams get wrong about group-based permissions?
A: They often treat groups as an admin convenience rather than an access control layer.
Practitioner guidance
- Re-scope broad roles to resource-level boundaries Map every custom role to the smallest meaningful resource type, then validate whether organisation-wide assignment still exists anywhere in the access model.
- Put group membership under access review Treat group creation, membership changes, and removals as governed events with logging, approval, and periodic certification.
- Protect self-serve email changes as recovery events Monitor mailbox changes, require verification paths that cannot be bypassed, and alert on changes involving external domains, suspended accounts, or privileged users.
What's in the full announcement
WorkOS's full update covers the operational detail this post intentionally leaves for the source:
- The exact dashboard and API flow for creating resource-scoped custom roles.
- Step-by-step examples for managing group memberships through the new Groups API.
- The verification and fallback mechanics behind self-serve email changes.
- Admin Portal configuration details for collecting and maintaining multiple IT contacts.
👉 Read WorkOS’s April updates on scoped roles, Groups API, and email change flows →
Role scoping, Groups API, and email change flows: what changes now?
Explore further
06/06/2026 3:35 am
Scoped roles are strongest when the scope boundary matches the access boundary. Resource-scoped custom roles reduce the blast radius of an overly broad entitlement, but only when teams model the actual resource hierarchy with care. A role that is safe at organisation level may still be excessive at project level if downstream permissions inherit too much by default. Practitioners should treat scoping as a governance decision, not a UI setting.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should own operational identity contacts in enterprise environments?
A: Operational identity contacts should be owned like control points, not like directory metadata. The right owners are the people responsible for SSO, directory sync, certificate renewal, and recovery operations, with clear approval rules for additions and removals. If contact ownership is vague, recovery and administration become harder to audit and easier to misuse.
👉 Read our full editorial: WorkOS April updates tighten role, group, and contact governance
