Having discussed cybersecurity needs and solutions for modern IAM in earlier articles, we can now explore the implementation steps. A phase-by-phase approach prioritises security throughout the software development lifecycle, providing a platform-independent direction. This guide uses code examples to demonstrate common security patterns, not platform-specific implementations.

If you haven't seen it yet, take a look at our previous IAM-centric article to learn how to choose the right identity access management solution for your business.

IAM solution implementation is divided into seven distinct phases:

• Phase 1: Strategic Planning and Security Analysis

• Phase 2: Solution Design and Customisation

• Phase 3: Integration and Deployment

• Phase 4: Training and Change Management

• Phase 5: Testing and Validation

• Phase 6: Monitoring and Continuous Improvement

• Phase 7: Future Growth and Scalability

The article will focus on Zero Trust concepts, therefore targeting phases 1, 2, and 3.

Phase 1: Strategic Planning and Security Analysis

Secure IAM implementation starts with threat modelling (e.g., STRIDE) to find and address potential attack vectors before production. To understand the full attack surface, this analysis needs to include digital infrastructure, applications, and network architecture.

Nowadays, IAM systems must comply with the NIST Cybersecurity Framework 2.0, specifically the GOVERN function for risk management and IDENTIFY for asset inventory (users, privileged accounts, access points). The PROTECT function handles strong authentication and authorisation, and DETECT provides ongoing monitoring.

This phase requires organisations to create a catalogue of all identity repositories, systems, and data flows. This inventory shows the size and complexity of the identity ecosystem, highlighting security vulnerabilities attackers could use. Significant security risks are often revealed during mapping, such as shadow IT and forgotten service accounts.

The security architecture must integrate GDPR, HIPAA, SOX, and PCI-DSS regulatory compliance from the start. Each specific compliance might shape how the IAM solution is implemented and monitored, while having a lot of common security requirements for authentication and authorisation.

Phases 2 & 3: Zero Trust Design and Implementation

Zero Trust, as we covered it in previous articles, states “never trust, always verify.”

With Zero Trust, authentication and authorisation are fundamentally changed. Using a multi-layered approach, verifying every access request through a series of security protocols. As opposed to relying on the implicit trust afforded by network location, each request needs to include detailed contextual data to allow for instant authorisation checks. This architectural shift requires reimagining how applications interact with identity and authorisation services, especially if it’s designed with this security concept from the ground up.

Zero trust operates through interconnected components:

• Centralised Policy Decision Points (PDPs) authorising access,

• Policy Enforcement Points (PEPs) intercepting every attempt with a distinct click, continuous verification engines constantly assessing session risk,

• just-in-time access systems eliminating lingering privileges,

• microsegmentation controls verifying network-level identities,

All of them create a layered security approach (Defence-In-Depth principle).

Further, we will explore the foundational mechanisms of zero trust through code examples.

Policy Enforcement Points (PEPs)

Policy Enforcement Points (PEPs), acting as a distributed enforcement layer, intercept every resource access attempt; before each attempt is passed to the Policy Decision Point (PDP) for authorisation, they are checked. In contrast to traditional network firewalls with their static rule-based filtering, PEPs require real-time access decisions from a central PDP for each request. This necessitates extremely fast query and response times, ideally sub-100ms to avoid impacting system performance and user experience, with sub-50ms preferred for high-frequency operations. The speed demands put a strain on the system architecture.

Policy Decision Point (PDP)

Here, Policy Decision Point (PDP) acts as the central authorisation engine, evaluating requests and enforcing policies in real-time. Typically, dynamic policies consider user attributes, resource context, environmental factors, and real-time risk assessment. Implementation demands crafting APIs capable of managing a high-frequency rate of authorisation requests, each demanding an accurate and relevant response.

The risk scoring algorithm can use threat intelligence feeds to assess IP reputation and mobile device management APIs to check compliance. Machine learning models can be integrated to detect behavioural anomalies, providing a more accurate threat assessment that is not based only on defending against common possible vulnerabilities, such as those presented in the OWASP Top 10.

Policy Evaluation

Policy evaluation uses attribute-based decision logic, dynamically adapting to context through the evaluation of various contextual attributes. In general, zero-trust policies evaluate multiple attributes simultaneously to make nuanced authorisation decisions.

Continuous Verification

To ensure continuous verification, you can implement risk-based authentication. This calls for additional authentication steps when contextual factors change, such as location or device. The system continuously monitors user actions and surrounding conditions, flagging unusual activity for review. Another interesting area where machine learning can be of great help.

JIT access with automatic revocation

Some issues come with traditional methods:

• Admins have access even when it is not needed.

• Admin accounts that have been compromised allow immediate, high-level access.

• A large attack surface is created by numerous accounts with permanent privileges.

• It’s hard to audit how privileges are actually used.

Just-in-time (JIT) access provisioning changes privileged operations management by removing always-on access and demanding explicit authorisation for each sensitive action, thus tightening security. This approach minimises security risks by using elevated permissions only when actively required, thus decreasing the window of vulnerability.

Microsegmentation

To implement microsegmentation, network controls must be in place to apply zero-trust at the most granular level, examining every network packet for security compliance. Software-defined perimeters establish secure, encrypted tunnels; a thorough identity verification process precedes any network communication.

Local policy caching

The core problem is that PEPs depend on the PDP for every access request, creating a vulnerability: What happens when the PDP is unavailable, leading to potential disruptions in access control functionality and a need for robust fallback mechanisms? Network problems, heavy use, or scheduled maintenance may disrupt access completely.

To maintain operation during network disruptions, local policy caching is used; however, cache expiration policies must balance operational continuity and security needs.

Phase 4: Training and Change Management

The success of a secure IAM design and implementation relies heavily on organisational adoption and technical execution. "We are as secure as our weakest link" extends beyond design and implementation. Therefore, in this phase, our attention turns to preparing stakeholders. From security administrators to business users, training needs to take place to ensure the behavioural and procedural changes introduced by the new identity framework are well understood.

Stakeholder training should be role-specific and grounded in an operational context. For example, IT staff and IAM administrators need deep familiarity with provisioning logic, policy enforcement points, and exception handling mechanisms. Security teams would want to focus more on evaluating IAM logs, to correlate events and, lastly, apply mitigation protocols. For end-users, the attention is shifted to interaction, understanding the new multifactor authentication workflows.

Training should at least cover:

• Tech onboarding

• Expected behaviours

• Incident reporting

• Staying updated on policy changes

Awareness and desire alone do not necessarily lead to adoption. This is where following an already established and proven protocol might be beneficial. Frameworks are assets that ensure company-wide alignment and maintain standards across different companies that adopt similar principles.

In the training phase, we recommend frameworks such as the ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement), a proven plan for managing change at an individual level. Rather than issuing general documentation or isolated training modules, organisations could embed IAM concepts in ongoing knowledge programs. This can include awareness campaigns, live simulations, and interactive sessions.

• Awareness: the IAM system's role in securing access and protecting sensitive data should be communicated. For example, explaining why Zero Trust policies are replacing legacy VPN access.

• Desire: addressing concerns and listing the benefits of IAM (e.g., faster login, fewer password resets), which helps reduce resistance.

• Knowledge: role-based training for users, admins, and security teams, ensuring they know how to interact with the system correctly.

• Ability: Hands-on sessions to showcase configuring MFA or managing access requests.

• Reinforcement: Conducting periodic reviews and collecting feedback.

On the other hand, change management can be addressed in parallel to avoid organisational resistance and cultural friction. Deeper psychological factors could affect people's reactions to disruption. Like the resistance often met with drastic updates to new frameworks and tools, IAM changes can be perceived as reducing autonomy. This is especially true when stricter access approval processes or mandatory MFA are implemented. Technical confusion can also be a source of resistance.

Communicating the benefits of role-based access control (RBAC), Zero Trust enforcement, and least-privilege models can help shift the perception from security as an obstruction to security as the new normal. Success metrics at this stage include a reduction in ticket volume for identity-related issues, as well as achieving compliance alignment across departments.

Change Management should focus on empathy, transparency, and early stakeholder engagement. It's essential to clearly explain why the change is occurring. Addressing security, compliance, and long-term efficiency has a greater impact than technical briefings by themselves.

Phase 5: Testing and Validation

Once users are prepared and new access patterns are introduced, the next task is confirming that the IAM system performs as expected: securely, consistently, and in alignment with organisational policy.

IAM testing will need, at its core, functional correctness, security assurance, and compliance adherence. This phase ensures that identities interact with systems only in the ways explicitly permitted, and that exceptions are predictable, auditable, and traceable. The system not only needs to be resistant to breaching and tampering but also to protect any sensitive information in the event of an error or when its services are disrupted.

Functionality testing starts with validating the full lifecycle of identities across several integration points:

• HRIS systems

• Directory services

• SaaS platforms

• Cloud infrastructure

Functional testing should include scenarios such as onboarding a new hire, granting temporary project-based access, or revoking privileges following offboarding. Importantly, you should also exercise negative test cases:

• Intentionally denied logins

• Failed privilege escalations

• Expired credentials

Beyond functionality, security and compliance testing play an important role. Validation includes testing multifactor authentication enforcement, privilege elevation boundaries, and group membership propagation across federated applications.

Established frameworks offer a structured format that ensures you eliminate all typical blind spots:

• NIST CSF 2.0, particularly the Protect and Detect functions, emphasises the need for proactive safeguards and real-time monitoring validation.

• MITRE ATT&CK techniques such as T1078 (Valid Accounts) and T1556 (Modify Authentication Process) can be simulated to assess resilience against real-world adversary behaviour.

In certain regulated industries, controls must also be tested against GDPR, SOX, HIPAA, or ISO 27001 requirements.

A frequent mistake in this phase is underestimating cross-application policy drift. As an example, a provisioning workflow could successfully provide access to a cloud document repository. However, it could fail to revoke access in a connected BI tool, due to SCIM attribute mapping discrepancies or inconsistent identity aliases. Such inconsistencies could cause privileges to persist beyond the boundaries set by governance policies.

Automation is key. Therefore, after understanding the validation requirements, we can then implement continuous validation pipelines, where IAM changes are tested in staging environments and are subjected to policy-as-code reviews.

In short, Phase 5 ensures that the architecture, design, and implementation work from both theoretical and practical viewpoints.

The best way to guarantee that IAM is fit for purpose is by establishing functional testing as a foundation, implementing policy validation, and building confidence through attack simulation testing.

Phase 6: Monitoring and Continuous Improvement

Now, once the IAM platform is operational, we can shift focus towards observability and adaptation. Phase 6 establishes IAM as a living, continuously monitored, measured, and refined product.

System Monitoring usually refers to uptime checks or log aggregation. However, as with every phase, things might become more complicated, the more we want to ensure policy and security. Therefore, it extends to:

• Failed and successful login attempts, particularly from anomalous geolocations or devices

• MFA bypass attempts or repeated failures that may indicate credential stuffing

• Dormant or orphaned accounts, which present silent but critical risks

• Privilege escalations, especially those outside standard change windows

And again, automation is key. Once we have a foundational dataset, we can optimise it further by integrating IAM logs into SIEM and SOAR platforms for automated correlation and faster incident response. At this stage, we may encounter information overload or false positives. However, to extract behavioural baselines via User and Entity Behaviour Analytics (UEBA), we must carefully decide how thorough or precise we want to be while also ensuring we can detect anomalies.

In terms of useful frameworks, NIST CSF 2.0 Detect and Respond functions provide a structure that our IAM platforms can then implement the "if-this-then-that" logic to handle security events in a controlled, predictable way. It ensures a step-up from collecting logs to enforcing real-time response. For example, detecting unusual access patterns should trigger adaptive policies such as step-up authentication, session termination, or temporary account suspension.

Again, the goal is signal over noise. One of the common pitfalls in this phase is alert fatigue, where excessive or low-priority alerts desensitise operations teams to genuine threats. To counter this, thresholds and policies should be tuned iteratively, stepping back and using real-world usage data to balance sensitivity.

Continuous improvement is essential for any type of project throughout its long-term journey. User experience feedback, whether from helpdesk tickets or surveys, offers insight into common friction points. For example, if users consistently report frustration with MFA prompts during certain workflows, adaptive authentication rules may need tuning.

Periodic access reviews and governance audits should feed back into policy adjustments. If role definitions result in repeated access requests for temporary overrides, that signals a misalignment between policy intent and operational reality. This phase ensures the system remains not just functional, but continuously aligned with business objectives, regulatory frameworks, and emerging threat models.

Phase 7: Future Growth and Scalability

Like with software in general, an IAM platform is never truly "finished." As organisations grow, integrate new technologies, or adapt to shifting regulations, the identity fabric must also grow with them. Phase 7 ensures that the IAM system remains scalable, adaptable, and strategically aligned for the long term.

Scalability assessment begins by evaluating the system's ability to handle growth across multiple dimensions:

• User volume: The system should handle a larger user base, including employees, roles, contractors, partners, and service accounts, without performance issues or provisioning bottlenecks.

• Integration complexity: The challenge of managing identities and maintaining consistent governance across new SaaS tools, hybrid workloads, and partner ecosystems.

• Policy depth: Enhance access models, such as upgrading from RBAC to ABAC or utilising policy-as-code, all while ensuring auditability and optimal performance levels.

This requires architecture that is loosely coupled and standards-driven. SCIM for provisioning and OAuth 2.1/OpenID Connect for federation enable identity to scale without rewriting core services.

OPA and other policy-as-code frameworks enable you to externalise policy logic, allowing for centralised, consistent enforcement, even in mixed environments.

A microservices architecture or separation of duties (SoD) principle, applied from the planning and design phase, can be very effective both for the implementation of an IAM solution and for handling context driven by external factors, such as policy.

The approach of compartmentalising all core features in a modular way allows us to make way for scalable technology updates. By prioritising platform neutrality and API-driven extensibility, we can integrate new capabilities without expensive or complete redesigns. For example, experimenting with biometric factors in parallel to the existing MFA stack and gradually maturing the authentication strategy is now viable, with a loosely coupled architecture.

In terms of governance, process is just as important as technology for scalability. Managing IAM policies as version-controlled code ensures consistent compliance, even as the system grows.

For instance, merging or acquiring another company often reveals fragile IAM designs when incorporating thousands of new identities and systems. Companies that have adopted standards-based federation and a modular architecture can easily incorporate these new entities. Comparatively, those relying on tightly coupled or proprietary platforms often encounter expensive and precarious rebuilds.

Ultimately, the most tangible way to futureproof IAM is to design with adaptability in mind. A scalable IAM ecosystem is one where changes can be absorbed with minimal friction.

Interested in what the future holds for Identity and Access Management solutions? Check out what our specialists see as the most important industry conditions and how they will affect future trends.

Or take a look at our results implementing Identity and Access Management solutions in the Manufacturing industry and in Finance.