Identity Security Control Framework - Product Manager Guide¶
Purpose¶
This document translates the Identity Security Control Framework into a product-oriented artifact. It is intended to help Product Managers: - Understand the conceptual model - Anchor roadmap and UX decisions - Align features to real customer problems - Maintain coherence across products and personas
1. Core Framework: Anatomy of Access¶
The framework describes identity-mediated access as a system of control surfaces.
Control Surfaces¶
- Identity Subject
- Who or what exists as an identity (human, service, workload, agent)
-
Attributes, ownership, lifecycle, trust tier
-
Device
- Execution environment asserting the identity
-
Endpoint, VM, container, CI runner
-
Network
-
Source, path, and trust assumptions of connectivity
-
Authentication
- How identity is proven
-
Factors, tokens, certificates, device signals
-
Authorization
- What is allowed, when, and under what conditions
-
Roles, policies, time-bound elevation
-
Targets
-
Systems, data, and services being accessed
-
Audit
- Evidence of access, intent, and outcome
- Logs, sessions, approvals, attestations
Principle: These are orthogonal control dimensions, not product categories.
2. Core Personas¶
2.1 Identity & Access Owner (IAM / IGA Lead)¶
Accountability - Identity lifecycle correctness - Access justification and reviews
Primary Pains - Orphaned identities and entitlements - Review fatigue and low signal - Poor ownership clarity
2.2 Privileged Access / Platform Security Lead¶
Accountability - Preventing catastrophic misuse of access - Securing admin and service identities
Primary Pains - Standing privileges - Secrets sprawl - Lack of session visibility
2.3 Security Operations / Incident Response¶
Accountability - Detecting abuse - Understanding blast radius
Primary Pains - Disconnected logs - Weak attribution - Poor access narratives
2.4 Application / Platform Owner¶
Accountability - Availability and delivery - Delegated access decisions
Primary Pains - Security friction - Unclear entitlement models - Manual approvals
2.5 Developer / Automation Builder¶
Accountability - Reliable automation - Non-human access
Primary Pains - Secrets management - Identity lifecycle for workloads - Tooling misaligned with software workflows
3. Identity Lifecycle Activities¶
Identity security is experienced as ongoing work, not point-in-time access.
Canonical Lifecycle Activities¶
- Discovery
- Onboarding
- Change
- Review & Attestation
- Decommissioning
- Continuous Improvement
These activities cut across all control surfaces.
4. Lifecycle × Control Surface Matrix¶
| Lifecycle Activity | Identity Subject | Authentication | Authorization | Targets | Audit |
|---|---|---|---|---|---|
| Discovery | Identify all identities and owners | Identify auth methods | Identify entitlements | Map access paths | Identify evidence gaps |
| Onboarding | Create identity with attributes | Register auth methods | Assign baseline access | Grant system access | Begin evidence trail |
| Change | Update role/ownership | Adjust auth context | Modify entitlements | Expand/restrict access | Record justification |
| Review | Validate existence | Validate strength | Certify access | Validate necessity | Attestation records |
| Decommission | Disable/remove identity | Revoke credentials | Remove access | Cut access paths | Retain evidence |
PM Insight: Gaps in any cell represent product opportunities.
5. Core Product Design Principles¶
Derived directly from the framework.
Identity Subject¶
- Lifecycle-first UX
- Ownership must be explicit
- Identity type must be visible
Authentication¶
- Contextual, not modal
- Risk-based friction
- Signals over static factors
Authorization¶
- Time-bound by default
- Intent visible to user and approver
- Elevation ≠ entitlement
Audit¶
- Evidence-first design
- Human-readable narratives
- Built for investigations, not just logs
6. Representative User Stories¶
Identity & Access Owner¶
- As an IAM lead, I want to see all identity subjects and their owners so I can detect orphaned access.
- As an IAM lead, I want access reviews to surface risk, not just checkboxes.
Privileged Access Lead¶
- As a PAM owner, I want privileges to expire automatically so standing access is eliminated.
- As a PAM owner, I want full session evidence for privileged actions.
Security Operations¶
- As a SOC analyst, I want to reconstruct who accessed what, when, and why in one view.
- As a responder, I want to differentiate legitimate access from abuse quickly.
Application Owner¶
- As an app owner, I want to approve access based on intent and duration, not identity jargon.
- As an app owner, I want clear visibility into who can access my system.
Developer / Automation Builder¶
- As a developer, I want workloads to authenticate without long-lived secrets.
- As a platform engineer, I want identity controls that align with CI/CD workflows.
7. How PMs Should Use This Framework¶
- Roadmap planning: Ensure coverage across control surfaces and lifecycle stages
- UX design: Prevent feature sprawl by anchoring features to surfaces
- Discovery: Use personas and lifecycle gaps to validate real pain
- Decision making: If a feature cannot be placed cleanly, question its necessity
Final Principle¶
Access is an event.
Identity Security is a practice.
This framework governs the practice.