Identity and Access Management
Identity and access management (IAM) is the discipline of ensuring that the right individuals access the right resources at the right times for the right reasons. IAM encompasses the policies, processes, and technologies that manage digital identities and control what authenticated users can do within systems. For mission-driven organisations, IAM serves as the foundational security control upon which all other access decisions depend.
- Identity
- A unique representation of a person, service, or device within a system. An identity comprises attributes (name, email, department) and credentials (passwords, certificates, tokens) that together distinguish one entity from another.
- Authentication
- The process of verifying that an entity is who they claim to be. Authentication answers “Who are you?” through credential verification.
- Authorisation
- The process of determining what an authenticated entity is permitted to do. Authorisation answers “What can you access?” through policy evaluation.
- Identity Provider
- A system that creates, maintains, and manages identity information while providing authentication services to relying applications. Abbreviated as IdP.
- Directory Service
- A hierarchical database optimised for read-heavy access patterns that stores identity attributes and group memberships. LDAP-based directories remain common; cloud directories increasingly replace them.
- Provisioning
- The creation of user accounts and assignment of access rights across target systems. Deprovisioning reverses this process upon departure.
- Entitlement
- A specific access right within a target system, such as membership in an application role or permission to read a file share.
The identity problem
Every organisation faces a fundamental challenge: people need access to systems, but access creates risk. Each additional account increases attack surface. Each permission granted might be exploited. Each departed staff member whose access remains active represents a vulnerability. IAM addresses this challenge by establishing systematic controls over who can access what, automating repetitive access operations, and creating audit trails that demonstrate accountability.
The stakes for mission-driven organisations extend beyond conventional data protection. A compromised account at a humanitarian organisation might expose beneficiary locations to hostile actors. Excessive access at a child protection agency might allow inappropriate viewing of case files. Orphaned accounts from departed staff create both security vulnerabilities and compliance failures. IAM controls directly affect an organisation’s ability to uphold its duty of care.
Identity lifecycle
The identity lifecycle describes the states an identity passes through from creation to deletion. Understanding this lifecycle is essential because each transition represents both an operational requirement and a security control point.
+------------------+ | | +-------------->| PENDING | | | (pre-boarding) | | +--------+---------+ | | | | Identity verified | | Accounts created | v | +--------+---------+ | | | Rehire | | ACTIVE | (within | | | retention | +--------+---------+ period) | | | +------------+------------+ | | | | | | Transfer | Leave of | Terminate | | | absence | | v v v | +--------+----+ +-----+------+ +---+-----------+ | | | | | | | | | MODIFIED | | SUSPENDED | | OFFBOARDING | | | (new role) | | (inactive) | | | | +--------+----+ +-----+------+ +-------+-------+ | | | | | +-----+------+ | | | | | | Return | Grace period | v | expires | +-----+------+ | | | | v +-----------+ ACTIVE | +-------+-------+ | | | | +------------+ | ARCHIVED | | | +-------+-------+ | | Retention | period expires v +-------+-------+ | | | DELETED | | | +---------------+Figure 1: Identity lifecycle states and transitions
A pending identity exists when HR confirms a hire but the start date has not arrived. During this phase, identity data is collected, accounts are prepared, and access is provisioned but not activated. Organisations that lack a pending state often scramble to create accounts on day one, leading to incomplete provisioning and frustrated new starters.
An active identity has verified credentials and operational access. The active state encompasses the majority of an identity’s lifetime. Within this state, access rights change as roles evolve, but the identity itself remains continuously valid.
A modified identity has undergone a role change that affects access rights. The joiner-mover-leaver model treats internal transfers as significant events because access appropriate for one role is frequently inappropriate for another. A programme officer moving to finance requires different system access; retaining programme access while gaining finance access violates least privilege. Modification events trigger access reviews to add required entitlements and remove those no longer justified.
A suspended identity retains its account structure but cannot authenticate. Suspension serves several purposes: staff on extended leave maintain their identity for eventual return; accounts under investigation remain intact for forensic purposes; staff in notice periods may have authentication disabled while offboarding completes. Suspension differs from deletion in its reversibility.
An offboarding identity is progressing through departure procedures. This state triggers systematic deprovisioning: disabling authentication, revoking access to sensitive systems, transferring data ownership, and archiving audit records. The offboarding period typically spans 24 to 72 hours, during which automated and manual processes complete departure tasks.
An archived identity no longer authenticates and holds no active access, but its records persist for compliance and audit purposes. Retention periods vary by regulation and policy; 7 years is common for employment records. Archived identities may be restored if a former staff member returns within the retention window.
A deleted identity has been permanently removed after retention obligations expire. Deletion is irreversible and destroys associated attributes, group memberships, and audit linkages. Some organisations never fully delete identities, instead maintaining tombstone records that preserve audit trail integrity.
Access control models
Access control models define the logic by which systems determine whether to permit or deny access requests. Three models dominate: discretionary, role-based, and attribute-based. Each offers different trade-offs between administrative simplicity and policy expressiveness.
Discretionary access control (DAC) places access decisions in the hands of resource owners. The creator of a document determines who can view or edit it. The owner of a folder grants permissions to colleagues. DAC reflects how individuals naturally think about sharing but scales poorly. An organisation with 500 staff and 10,000 documents has 5 million potential access relationships. Without systematic governance, permissions drift, over-sharing becomes endemic, and access reviews become impractical.
Role-based access control (RBAC) groups permissions into roles that reflect job functions, then assigns users to roles rather than directly to permissions. A finance officer role might include access to the accounting system, expense reports, and budget files. When someone joins the finance team, assigning the finance officer role grants all necessary permissions in a single operation. When permissions must change, modifying the role affects all members simultaneously.
+-------------------------------------------------------------------+| RBAC MODEL |+-------------------------------------------------------------------+| || +-------------+ +-------------+ +-------------+ || | USERS | | ROLES | | PERMISSIONS | || +-------------+ +-------------+ +-------------+ || | | | | | | || | alice +-------->| Finance +-------->| ERP: read | || | | 1:N | Officer | 1:N | ERP: write | || | bob | | | | Budget: read| || | | +-------------+ | | || | carol +-------->| | +-------------+ || | | | Programme +-------->| | || | david +-------->| Manager | | CRM: read | || | | | | | CRM: write | || +-------------+ +-------------+ | M&E: read | || | | | | || | IT Admin +-------->+-------------+ || | | | | || +-------------+ | AD: admin | || | Server: root| || | | || +-------------+ |+-------------------------------------------------------------------+Figure 2: Role-based access control structure
RBAC effectiveness depends on role design. Too few roles forces over-permissioning; everyone in a broad role receives access they do not need. Too many roles recreates the administrative burden of individual permissions. Practical RBAC implementations maintain between 20 and 100 roles for organisations of 100 to 1,000 staff. The ratio of users to roles should fall between 5:1 and 50:1; falling outside this range signals design problems.
Attribute-based access control (ABAC) evaluates policies against attributes of the user, resource, action, and environment. Rather than pre-defined role assignments, ABAC policies express rules: “Users in the legal department may access contracts marked as legal-review during business hours from managed devices.” ABAC provides fine-grained control that RBAC cannot match. A single ABAC policy can express what would require dozens of RBAC roles.
+--------------------------------------------------------------+| ABAC POLICY ENGINE |+--------------------------------------------------------------+| || +------------------+ || | ACCESS REQUEST | || +------------------+ || | User: alice | || | Action: read | || | Resource: doc123 | || | Time: 14:30 UTC | || | Device: managed | || +--------+---------+ || | || v || +--------+---------+ +--------------------+ || | | | USER ATTRIBUTES | || | POLICY |<----+--------------------+ || | DECISION | | department: legal | || | POINT | | clearance: high | || | | | location: HQ | || | Evaluates: | +--------------------+ || | | || | IF user.dept | +--------------------+ || | = resource | | RESOURCE ATTRIBUTES| || | .dept |<----+--------------------+ || | AND user.clear | | classification: | || | >= resource | | confidential | || | .class | | department: legal | || | AND device | | owner: bob | || | .managed | +--------------------+ || | = true | || | AND time | +--------------------+ || | BETWEEN | | ENV ATTRIBUTES | || | 08:00-18:00 |<----+--------------------+ || | | | business_hours: Y | || | THEN permit | | threat_level: low | || | | +--------------------+ || +--------+---------+ || | || v || +--------+---------+ || | PERMIT | || +------------------+ |+--------------------------------------------------------------+Figure 3: Attribute-based access control evaluation
ABAC requires richer infrastructure than RBAC. Attributes must be maintained accurately across systems. Policy engines must evaluate potentially complex rules at request time. Administrators must understand policy logic to troubleshoot access denials. For these reasons, pure ABAC implementations remain less common than RBAC, though hybrid approaches that add attribute conditions to role-based foundations offer practical middle ground.
Most organisations benefit from RBAC as the primary model with selective ABAC augmentation. Roles handle the 80% of access that follows predictable patterns; attribute policies address the 20% requiring contextual evaluation. This hybrid approach delivers RBAC’s administrative simplicity while enabling ABAC’s precision where justified.
IAM architecture
IAM architecture describes how identity components connect and interact. The architecture varies by organisation size, cloud adoption, and legacy system presence, but common patterns emerge.
+--------------------------------------------------------------------------+| IAM ARCHITECTURE |+--------------------------------------------------------------------------+| || +-------------------------------------------------------------------+ || | IDENTITY GOVERNANCE LAYER | || | | || | +----------------+ +----------------+ +----------------+ | || | | Access | | Role | | Compliance | | || | | Certification | | Management | | Reporting | | || | +----------------+ +----------------+ +----------------+ | || +-------------------------------------------------------------------+ || | || v || +-------------------------------------------------------------------+ || | IDENTITY MANAGEMENT LAYER | || | | || | +------------------+ +------------------+ +----------------+ | || | | Identity | | Directory | | Credential | | || | | Provider | | Services | | Management | | || | | | | | | | | || | | - Authentication | | - User store | | - Passwords | | || | | - MFA | | - Group store | | - Certificates | | || | | - SSO | | - Attributes | | - Keys | | || | | - Federation | | - Hierarchy | | - Tokens | | || | +--------+---------+ +--------+---------+ +-------+--------+ | || | | | | | || +-------------------------------------------------------------------+ || | | | || +---------------------+--------------------+ || | || v || +-------------------------------------------------------------------+ || | PROVISIONING LAYER | || | | || | +------------------+ +------------------+ +----------------+ | || | | HR Integration | | Provisioning | | Workflow | | || | | | | Engine | | Engine | | || | | - Joiner events | | | | | | || | | - Mover events | | - Account create | | - Approvals | | || | | - Leaver events | | - Entitlement | | - Escalations | | || | | | | assignment | | - Notifications| | || | +--------+---------+ +--------+---------+ +-------+--------+ | || +-------------------------------------------------------------------+ || | || v || +-------------------------------------------------------------------+ || | TARGET SYSTEMS | || | | || | +----------+ +----------+ +----------+ +----------+ | || | | Cloud | | On-prem | | SaaS | | Legacy | | || | | Platform | | Apps | | Apps | | Systems | | || | +----------+ +----------+ +----------+ +----------+ | || +-------------------------------------------------------------------+ |+--------------------------------------------------------------------------+Figure 4: IAM component architecture
The identity provider serves as the authoritative source for authentication decisions. When a user attempts to access any integrated system, that system delegates authentication to the IdP. This delegation enables single sign-on: one successful authentication grants access to all relying systems. Modern IdPs support multiple authentication methods, multi-factor authentication, conditional access policies, and federation protocols.
Directory services store identity attributes and group memberships. Traditional LDAP directories like OpenLDAP or Active Directory provide hierarchical storage with fast read performance. Cloud directories built into platforms like Microsoft Entra ID or Google Workspace combine directory functions with identity provider capabilities. Many organisations operate hybrid directories that synchronise identities between on-premises and cloud stores.
Provisioning engines automate account creation and entitlement assignment across target systems. When HR records a new hire, the provisioning engine creates accounts in all systems the new role requires. Connectors translate generic provisioning commands into system-specific operations. Without automated provisioning, IT staff manually create accounts across 10, 20, or more systems for each joiner, introducing delay and error.
The workflow engine routes requests requiring human decision to appropriate approvers. A request for elevated access routes to the data owner and line manager. A role change request routes to the new manager and security team. Workflow automation ensures requests follow consistent approval paths and creates audit trails of decisions.
Identity governance encompasses the controls that ensure IAM operates correctly over time. Access certification campaigns verify that current access remains appropriate. Role management maintains role definitions as organisational structure evolves. Compliance reporting demonstrates adherence to policies and regulations. Without governance, IAM implementations drift toward over-permissioning and inconsistency.
Directory architecture patterns
Directory architecture depends heavily on organisation structure, cloud adoption, and legacy system presence. Three patterns cover most scenarios.
Cloud-primary architecture uses a cloud identity provider as the authoritative source. Staff identities exist in Microsoft Entra ID, Google Workspace, or Okta. On-premises systems either integrate directly via federation or synchronise identity data from the cloud source. This pattern suits organisations without significant legacy infrastructure or those prioritising operational simplicity over control.
+------------------------------------------------------------------+| CLOUD-PRIMARY ARCHITECTURE |+------------------------------------------------------------------+| || +-------------------+ || | Cloud IdP | || | (Authoritative) | || | | || | - User store | || | - Groups | || | - Authentication | || +--------+----------+ || | || +---------------------+---------------------+ || | | | || v v v || +------+------+ +------+------+ +------+------+ || | SaaS Apps | | Cloud | | On-premises | || | (native) | | Platform | | (sync agent)| || +-------------+ +-------------+ +-------------+ || |+------------------------------------------------------------------+Figure 5: Cloud-primary directory pattern
Hybrid architecture maintains on-premises Active Directory as the authoritative source while synchronising identities to cloud services. Azure AD Connect or Google Cloud Directory Sync replicates users and groups to the cloud, enabling cloud application access while preserving on-premises authority. This pattern dominates among organisations with established on-premises infrastructure and gradual cloud adoption.
+------------------------------------------------------------------+| HYBRID ARCHITECTURE |+------------------------------------------------------------------+| || +-----------------------------+ || | ON-PREMISES | || | | || | +----------------------+ | +----------------------+ || | | Active Directory | | | Cloud IdP | || | | (Authoritative) +---+----->| (Synchronised) | || | | | | Sync | | || | +----------+-----------+ | +----------+-----------+ || | | | | || | v | v || | +----------+-----------+ | +----------+-----------+ || | | On-prem applications | | | Cloud applications | || | +----------------------+ | +----------------------+ || +-----------------------------+ || |+------------------------------------------------------------------+Figure 6: Hybrid directory pattern
Federated architecture connects multiple independent identity sources through trust relationships. Organisations undergoing mergers maintain separate directories that mutually trust each other. Consortiums of independent organisations federate to enable collaboration without centralising identity. Each participating directory remains authoritative for its own users while accepting authentication assertions from trusted partners.
+------------------------------------------------------------------+| FEDERATED ARCHITECTURE |+------------------------------------------------------------------+| || +------------------+ +------------------+ || | Organisation A | | Organisation B | || | Directory |<---- Federation --->| Directory | || | (Authoritative | Trust | (Authoritative | || | for Org A) | | for Org B) | || +--------+---------+ +--------+---------+ || | | || v v || +--------+---------+ +--------+---------+ || | Org A apps | | Org B apps | || | + Shared apps | | + Shared apps | || +------------------+ +------------------+ || || +------------------+ || | Shared Services | || | (accepts both | || | IdPs) | || +------------------+ || |+------------------------------------------------------------------+Figure 7: Federated directory pattern
Selecting a pattern requires evaluating several factors. Cloud-primary simplifies operations but creates dependency on a single provider and may raise data sovereignty concerns depending on provider jurisdiction. Hybrid preserves existing investments but adds synchronisation complexity and potential consistency issues. Federation enables collaboration but requires governance across organisational boundaries.
Identity governance
Identity governance ensures that access rights remain appropriate over time. Without active governance, access accumulates. A staff member who changed roles three times over five years may retain access from all previous positions. A project team disbanded two years ago may still have active group memberships. Governance mechanisms counteract this drift.
Access certification requires managers and system owners to periodically confirm that current access remains justified. A typical certification campaign presents each reviewer with their direct reports’ access entitlements. The reviewer must either certify each entitlement as still required or flag it for revocation. Certification frequency varies by risk: privileged access certifies quarterly; standard access certifies annually.
The effectiveness of access certification depends on reviewer capability. A manager reviewing 50 entitlements across 10 systems for 8 staff faces 400 decisions. Without guidance on what each entitlement permits, reviewers rubber-stamp approvals. Effective certification provides reviewers with entitlement descriptions, flags unusual patterns, and tracks approval rates to identify reviewers who approve everything without scrutiny.
Segregation of duties (SoD) prevents any single individual from controlling all aspects of critical processes. The person who requests payments should not approve them. The administrator who creates accounts should not review access. SoD rules define incompatible permission combinations. The IAM system prevents assignment of conflicting roles and alerts when violations occur.
Implementing SoD requires mapping business processes to identify control points and defining which combinations create unacceptable risk. A worked example: payment processing involves request, approval, and execution. The SoD matrix prohibits holding both request and approval roles, or both approval and execution roles. When provisioning detects a request that would create a violation, it routes to an exception approval process requiring documented business justification and compensating controls.
Role lifecycle management maintains role definitions as organisations evolve. Roles created for a specific project may persist after the project ends. Roles defined for a departed team may contain obsolete permissions. Regular role reviews identify roles with zero or few members, roles with excessive permissions, and roles with significant membership overlap suggesting consolidation opportunities.
IAM and zero trust
Zero trust architecture assumes no implicit trust based on network location. Every access request is authenticated, authorised, and encrypted regardless of whether it originates inside or outside the network perimeter. IAM provides the identity verification that zero trust requires.
Traditional security models grant broad access once a user connects to the corporate network. The perimeter firewall distinguishes trusted from untrusted. Inside the perimeter, access controls may be minimal. This model fails when staff work remotely, when cloud applications exist outside the perimeter, and when attackers breach the perimeter and move laterally.
Zero trust replaces perimeter-based trust with identity-based trust. The network location of a request provides no inherent privilege. Instead, each request presents identity credentials. The system verifies identity through the IdP, evaluates authorisation policies, and permits or denies based on the combination of who is asking, what they want, from what device, under what circumstances.
IAM capabilities that support zero trust include strong authentication (verifying identity claims), continuous authorisation (re-evaluating access as context changes), and comprehensive audit (recording all access decisions for analysis). Organisations pursuing zero trust strategies must first establish mature IAM foundations. Without reliable identity verification, zero trust policies cannot function.
Implementation considerations
IAM implementation varies significantly based on organisational context. The appropriate approach for a 50-person charity with one IT generalist differs fundamentally from that suitable for a 5,000-person federation with regional IT teams.
Organisations with minimal IT capacity
When one person manages IT alongside other responsibilities, IAM implementation must prioritise impact per hour of effort. Begin with a cloud identity provider that includes directory services, authentication, and basic provisioning. Microsoft 365 nonprofit licensing includes Entra ID at no cost for qualifying organisations. Google Workspace for Nonprofits provides Google Cloud Identity. Keycloak offers a self-hosted open source alternative for organisations preferring control over convenience.
Configure the identity provider as the authentication source for all applications that support modern protocols. Most SaaS applications support SAML or OIDC federation. Each federated application removes one password for users to manage and one account for IT to provision and deprovision independently.
Focus initial effort on the highest-risk identity lifecycle events: joiners and leavers. Create a checklist of systems requiring account creation for new staff and execute it consistently. Create a corresponding checklist for departures. Automated provisioning can wait; consistent manual processes eliminate the worst gaps.
Implement multi-factor authentication for all users, prioritising administrators and staff with access to sensitive data. Authenticator applications provide adequate security for most contexts at zero cost. Hardware security keys offer stronger protection for high-risk roles if budget permits.
Defer sophisticated capabilities like access certification campaigns, automated provisioning, and comprehensive role engineering until capacity allows. The gap between “no systematic IAM” and “basic cloud IAM with MFA” delivers more security improvement than the gap between “basic IAM” and “sophisticated IAM.”
Organisations with established IT functions
Dedicated IT teams can implement more comprehensive IAM programmes. The priority shifts from establishing basics to eliminating inconsistency and building automation.
Conduct an identity source audit. Many organisations accumulate multiple directories: Active Directory from one era, a cloud directory from another, application-specific user stores never integrated. Document all identity sources and classify each as authoritative, synchronised, or orphaned. Define a target architecture that establishes clear authority and eliminates redundant stores.
Implement automated provisioning for high-volume onboarding scenarios. The automation investment justified by time savings depends on scale. An organisation onboarding 200 staff annually saves more hours than one onboarding 20. Start with systems requiring the most manual provisioning effort and expand coverage incrementally.
Establish a role engineering programme. Document current access patterns by extracting entitlement data from target systems. Analyse clustering: which users share similar access? Define roles that capture these clusters. Validate proposed roles with business stakeholders who understand job functions. Implement roles and migrate users from direct entitlements. Plan for ongoing role maintenance as business needs evolve.
Implement access certification appropriate to organisational risk. Annual certification of all access suits low-risk environments. Quarterly certification of privileged access with annual certification of standard access balances effort against risk. Track certification metrics: completion rates, approval rates, revocation rates. Low revocation rates may indicate rubber-stamping rather than careful review.
Consider identity governance platforms that integrate provisioning, certification, and role management. Open source options like Midpoint provide comprehensive capabilities for organisations with technical capacity. Commercial platforms like SailPoint, Saviynt, or One Identity offer managed alternatives with vendor support.
Organisations with federated structures
Federated organisations face unique IAM challenges. Country offices or member organisations may operate independently, selecting their own systems and managing their own identities. Central IT influence varies from advisory to authoritative. Imposing a single IAM architecture may exceed central authority, yet identity fragmentation impedes collaboration and creates security inconsistency.
Federation-friendly approaches establish common standards while permitting local implementation choice. Define an identity interoperability standard specifying protocol support, attribute requirements, and security minimums. Participating entities that meet the standard can federate with shared services regardless of their internal IAM architecture.
Implement a federation hub rather than point-to-point trust relationships. Each participating entity establishes trust with the hub once. The hub then brokers authentication across all participants. Adding new participants requires one trust relationship rather than N-1 relationships with existing participants.
Accept that consistency will be imperfect. Track identity maturity across federated entities using a common assessment framework. Identify high-risk gaps such as entities lacking MFA or lacking leaver processes. Prioritise capacity building for entities with critical gaps while accepting variation in non-critical areas.
Technology options
IAM technology selection balances capability, operational burden, cost, and jurisdictional considerations.
Open source identity providers
Keycloak provides enterprise-grade identity management including user federation, identity brokering, social login, and fine-grained authorisation. Red Hat sponsors development. Deployment requires container orchestration skills; Kubernetes deployments are typical. Suitable for organisations with DevOps capacity seeking control over identity infrastructure.
Authentik offers identity provider and application proxy capabilities with a more accessible deployment model than Keycloak. Single-container deployment simplifies initial setup. The application proxy feature enables secure access to applications lacking native SSO support.
Kanidm focuses on modern authentication methods including native FIDO2 support. Written in Rust with emphasis on security and performance. Less mature than Keycloak but developing rapidly.
All open source options require operational capacity for deployment, updates, and troubleshooting. The trade-off is control and cost savings versus vendor support and reduced operational burden.
Commercial identity platforms
Microsoft Entra ID integrates tightly with Microsoft 365. Organisations already using Microsoft 365 gain basic identity capabilities at no additional cost. Premium tiers add conditional access, privileged identity management, and access reviews. US-headquartered; CLOUD Act jurisdiction applies.
Google Cloud Identity provides similar capabilities for Google Workspace environments. Premium tier adds device management and enterprise security features. US-headquartered; CLOUD Act jurisdiction applies.
Okta offers identity platform capabilities independent of productivity suite. Strong application integration catalogue. Frequently selected by organisations seeking best-of-breed identity separate from productivity vendor. US-headquartered; CLOUD Act jurisdiction applies.
For mission-driven organisations handling sensitive data, jurisdiction matters. US-headquartered providers may be compelled to provide data access under the CLOUD Act regardless of where data is stored. Organisations managing protection data or operating in contexts where US government access creates risk should evaluate this factor alongside technical capabilities.