Custom IAM system development
Appfront designs and builds custom Identity & Access Management systems, and integrates existing IdPs such as Microsoft Entra ID, Okta, Auth0, Keycloak, ForgeRock, Ping Identity, AWS Cognito, Google Identity and JumpCloud into your application landscape. Workforce IAM for your employees, CIAM for your customers, federation across domains via SAML/OIDC, MFA rollout with passkeys and conditional access, all built around standards such as OAuth 2.1, OIDC, SAML 2.0, SCIM and FIDO2, and aligned with GDPR, NIS2, ISO 27001 and, where relevant, NEN 7510 and DORA.
What is an IAM system?
Identity & Access Management is the combination of processes, policies and software that enables an organisation to determine which digital identities exist, how they sign in, and what they are then allowed to do in which application. In practice, it comes down to four closely linked questions: who someone is (identity store and attributes), how you can be sure it is them (authentication, MFA, passkeys, conditional access), what that identity is allowed to do (authorisation, roles, policies, scopes), and how those rights remain accurate over time (lifecycle management, provisioning, de-provisioning, periodic access reviews).
For most organisations, an IAM system is not a standalone application but a layer beneath the entire application landscape. Employees sign in to a hundred SaaS tools, partners and customers log in to portals, and scripts and services communicate with one another via APIs. In every case, it must be clear which identity is involved and which rights apply. When done well, an IAM system replaces the sprawl of separate passwords, shared accounts and manual rights management with a unified layer that you can control centrally, monitor and demonstrate during audits.
Appfront builds custom IAM solutions for organisations where an off-the-shelf package no longer fits, and, in other projects, integrates an existing platform such as Microsoft Entra ID, Okta, Auth0, Keycloak, ForgeRock, Ping Identity, AWS Cognito, Google Identity, OneLogin or JumpCloud into a specific application stack. We focus on the technical link, covering single sign-on, federation, provisioning, and role-based and attribute-based access control, and tailor it to your actual organisational structure, security policy and compliance requirements. For projects that go beyond the boundaries of an API platform, we build on our broader API service and our integrations overview page as a starting point for the architecture.
One source of identity
A single canonical place for everyone who exists in your landscape, fed from HR, CRM or self-service registration. All applications talk to it via OIDC, SAML or SCIM, so there are no more separate user tables per tool.
MFA and passkeys
FIDO2/WebAuthn passkeys as the preferred factor, TOTP and push as fallbacks, and SMS only where truly necessary. Conditional access determines per action whether step-up is required.
Auditable access picture
For every action, traceable to who did it, with which factor, from which device, and in which role context. Logs in a format your SOC or SIEM (Splunk, Sentinel, ELK) can process directly.
Our process for an IAM project
An IAM project stands or falls on good groundwork: which identities exist, which applications are involved, which roles exist in HR and within the business, and which compliance requirements apply to the final solution. We work in four phases, with a concrete deliverable after each phase that your team can take forward, even if you decide after the first phase that a packaged-product-only route is the right one.
We take inventory of applications, identities, roles and current login flows. Outcome: an identity landscape map, a list of gaps in MFA coverage and an initial assessment of packaged product versus custom development.
We design the IAM architecture, select the primary identity provider, document federation and SCIM routes, and define the authentication and authorisation model. Conditional access policies and the choice between RBAC and ABAC are also decided at this stage.
Implementation in sprints, with automated tests, integration tests against the applications and a pilot group of real users. We write administration guides and walk through incident procedures with your IT team.
Phased roll-out per application or user population, with monitoring of login failures, MFA adoption and provisioning errors. This is followed by ongoing management, periodic access reviews and continued development.
What an Appfront IAM project concretely delivers
Every IAM engagement is set up around your actual organisation, application landscape and compliance requirements. A municipal department, a Dutch healthcare provider, a SaaS company with international customers and a mid-market industrial company will not get the same IAM. Below are the building blocks we most often deliver, regardless of the chosen IdP. For each flow we decide whether to use OIDC, SAML 2.0 or SCIM, depending on what the target application and your primary IdP support.
Single sign-on via OIDC or SAML 2.0
Signing in once to your primary IdP gives access to your entire permitted application landscape. We connect internal tools, SaaS applications and partner portals via OIDC or SAML 2.0, with the correct claims, scope mapping and token lifetimes per application.
MFA roll-out with passkeys
FIDO2/WebAuthn passkeys as the primary factor, with TOTP and push notifications as fallbacks. We tie MFA to a conditional access policy so users are only asked for a stronger factor when the device, location or action warrants it.
SCIM provisioning and deprovisioning
Accounts are automatically created, changed or removed based on a trigger from HR or another authoritative system. Deprovisioning on leaving the organisation happens within minutes rather than weeks, which is critical for NIS2 and ISO 27001 compliance.
Just-in-time and PAM
Privileged Access Management with temporary, just-in-time granted rights instead of permanent admin rights. Administrators request elevated rights for a specific task, with an approval flow, audit trail and automatic revocation.
Federation across domains
Cross-domain SSO via SAML or OIDC for partners, subsidiaries and merged organisations. A customer signs in to your environment with their own account, with clear agreements on attribute release, session lifetime and de-federation.
Audit trail and SIEM forwarding
Login events, MFA events, role changes and privileged actions are written to a structured audit log that is forwarded to your SIEM (Splunk, Microsoft Sentinel, Elastic). We supply detection rules for typical identity threats alongside it.
IdPs we integrate or replace
Most projects already have an IAM platform in place, sometimes well configured but more often grown organically with legacy configuration. Appfront works with the mainstream identity providers found in Dutch mid-market and enterprise organisations. For each IdP we know the particularities of claims mapping, federation quirks and the typical pitfalls in an upgrade project. For healthcare and the public sector we complement this with DigiD, eHerkenning, UZI pass and eIDAS nodes.
When custom development is the right choice
In the vast majority of projects, a packaged product is the right choice for most of the IAM challenge: Entra ID, Okta or Auth0 cover 80 to 95 per cent of what a typical organisation needs. Custom development comes into play where the package falls short: a specific authorisation rule that is too complex for the policy engine, a legacy system that does not speak modern federation, or a CIAM flow that must preserve your customers' brand experience. Below are four patterns in which we consistently see custom IAM (or a thin custom layer on top of a product) being needed.
Healthcare with BSN, UZI cards and patient context
Healthcare organisations work with the BSN as a personal identifier, UZI cards for healthcare professionals, and context-aware authorisation: a doctor may only view the record of a patient admitted to their ward. Rules of this kind rarely fit neatly into packaged RBAC. A custom layer on top of Keycloak or Entra ID, with proper BSN hashing and logging of the treatment relationship, aligns with the GDPR, NEN 7510 and the Wabvpz. See also our NEN 7510 page for the broader context.
B2B2C: your customer has customers of their own
You deliver a platform on which your business customer (a SaaS company, a franchisee, a dealer) manages its own end users. That calls for a multi-tenant identity model with tenant administrators, scope isolation and per-tenant branding of sign-in screens. Auth0 and Cognito can partly do this, but the finishing touches almost always require a custom abstraction layer. We integrate that with our broader API integration service, so the tenant configuration can be managed via API.
Legacy and mainframe alongside a modern IdP
A mainframe, AS/400, AIX application or classic client-server tool does not speak OIDC or SAML. For these scenarios we build a bridging layer: token exchange between a modern IdP and legacy authentication, with an audit trail on both sides. This way, employees benefit from modern SSO and MFA, while the old system keeps its own authentication protocol until it is replaced, at your pace.
Unique RBAC and ABAC rules
Some organisations have rules that cannot be captured in a standard policy engine: a combination of role, department, customer segment, geographic work area, contract type and time windows. For these scenarios we build an ABAC (Attribute-Based Access Control) layer that runs alongside the IdP, often using OPA (Open Policy Agent), so that policies remain declarative, testable and auditable.
Standards we build on
An IAM system that needs to last for years should lean as much as possible on open standards. This keeps vendor lock-in to a minimum and makes it possible to replace individual components (IdP, MFA provider, directory service) independently whenever necessary. Appfront chooses standardisation over the exotic, and localises custom work in the thinnest layer possible.
OpenID Connect and OAuth 2.1
The modern standard for authentication and delegated authorisation on web and mobile. It works with JWT tokens, PKCE for public clients, and fits well with SPA, mobile and server-side flows. We build every new application on this unless there is a compelling reason to choose SAML.
SAML 2.0
The de facto standard for enterprise SSO. Many older business SaaS applications, ERP and HRM packages support SAML rather than OIDC. We set up federation between your IdP and those applications, with the right attribute mapping and a certificate rotation schedule.
SCIM for provisioning
System for Cross-domain Identity Management is the modern open standard for provisioning and deprovisioning accounts across systems. A new employee entered in HR automatically lands in your IdP and in the connected SaaS applications, and when someone leaves, the reverse happens within minutes.
Passkeys with FIDO2/WebAuthn
The W3C standard for phishing-resistant authentication. A passkey on your phone or a hardware key replaces the password-plus-MFA screen. For customer-facing passkeys, they also substantially improve the login experience, a commercial gain alongside the security gain.
eIDAS, DigiD and eHerkenning
For public services and sectors where citizens sign in with DigiD, or businesses sign in with eHerkenning at an assurance level (EH2+, EH3, EH4). We integrate with the DigiD, eHerkenning and eIDAS nodes and make sure attribute handling meets the applicable requirements.
NIS2, ISO 27001 and DORA
NIS2 requires essential and important entities to implement explicit MFA, least privilege, lifecycle management and logging. ISO 27001 calls for a demonstrably managed identity process. For financial service providers, DORA adds requirements around ICT third-party risk, and IAM sits right at that intersection. Our ISO 27001 page provides more background on this.
Security and compliance: with IAM, they are the starting point, not an afterthought
An IAM system is by definition a security component: it is the gatekeeper of your application landscape. This means security and compliance are not verified at the end of the project but weighed in every design decision. Appfront works in line with OWASP ASVS and the NIST 800-63 guidelines for digital identity. For every new IAM environment we draw up a threat model (STRIDE), determine the privacy impact (a DPIA for sensitive populations such as healthcare or government) and ensure audit logs land in an immutable location. Our broader approach is set out in our information security policy.
In practice, this means in every IAM build: secrets held in a managed secrets store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), certificates with automated rotation, encryption in transit (TLS 1.3) and at rest, and separation of duties between development, acceptance and production environments. For PAM (Privileged Access Management) we use just-in-time access and periodic access reviews; permanent admin rights are the exception, not the rule. For CIAM, consent management, right-to-erasure flows and GDPR-compliant attribute management are added to that.
For NIS2-regulated organisations, we document how MFA coverage is secured, how lifecycle management is automated, how incidents are detected and reported, and how periodic access reviews are carried out. For healthcare organisations, we align the design with NEN 7510-3 (logging and monitoring), NTA 7516 (secure email) and the guidelines for processing BSN numbers. For financial services providers, we add DORA components covering third-party risk and ICT incident reporting.
Frequently asked questions about IAM
What clients most often ask us at the start of an IAM project, and what we typically answer before moving on to the detailed design.
IAM stands for Identity & Access Management: the combination of processes and software that determines who exists in an organisation's digital landscape, how each person signs in, and what they are allowed to do in which application. An IAM system brings together an identity store (where users and their attributes are held), authentication (sign-in plus MFA, passkeys, conditional access), authorisation (roles, policies, scopes) and lifecycle management (provisioning, de-provisioning, and adjusting access when someone changes role).
A product is by far the best choice for traditional workforce IAM with standard SaaS applications. Custom development becomes relevant when your use case doesn't fit what a product offers out of the box: niche CIAM with your own specific rules, B2B2C setups where your customers in turn manage their own customers, healthcare environments with BSN or UZI cards, a legacy mainframe or AS/400 that doesn't match a standard connector, or unique authorisation rules that require more complex policies than an out-of-the-box engine accepts. Often the right solution is a product for the core, plus a thin custom layer for the exceptions.
Appfront integrates with Microsoft Entra ID (formerly Azure AD), Okta, Auth0, Keycloak, ForgeRock, Ping Identity, AWS Cognito, Google Identity, OneLogin and JumpCloud. For the public and healthcare sectors we also integrate with DigiD, eHerkenning, UZI pass and eIDAS nodes. Integration runs via OIDC, SAML 2.0 or SCIM, depending on what the target application and the IdP support.
Workforce IAM governs access by your own employees to internal applications: a closed population whose lifecycle you control directly. CIAM (Customer IAM) governs access by your customers or end users to your products: an open population where self-service registration, social sign-in, passkeys, consent management and scale to millions of accounts come into play. The technical stack largely overlaps, but the requirements for UX, performance and privacy are fundamentally different. CIAM directly affects your customer experience; workforce IAM is largely invisible to the end user as long as it works.
By default we build MFA with FIDO2/WebAuthn as the preferred factor (passkeys on a phone or hardware key), with authenticator apps (TOTP) and push notifications as fallbacks. We only use SMS where legislation or a client contract requires it, as it is now regarded as a weak factor. We combine MFA with conditional access rules based on device trust, location, IP reputation and risk signals, and build step-up flows so that users are asked for a stronger factor only when the action warrants it. For CIAM, passkeys also deliver measurable conversion gains, as sign-in friction demonstrably drops.
NIS2 requires essential and important entities to take explicit access control measures: demonstrable MFA, least-privilege, structured lifecycle management, logging and incident response. A well-designed IAM system is the central tool for this. GDPR primarily affects the attribute store (which personal data, which lawful basis) and the retention periods for audit logs. For every engagement we document which data flows fall under NIS2 and which processing falls under GDPR, so the solution aligns with the security policy and the record of processing activities. For healthcare organisations, NEN 7510 applies as well; for financial service providers, DORA.
Yes. Appfront is regularly brought in to review, clean up and professionalise existing Entra ID, Okta, Auth0 or Keycloak environments. We carry out an access review of roles and groups, resolve role explosion, map orphaned accounts, revise conditional access policies and set up a working provisioning flow using SCIM where it makes sense. Afterwards, we can either hand over management to your own team with clear documentation, or continue to manage it alongside you. A clean-up almost always delivers measurable results straight away: fewer accounts, fewer permanent admin rights, and better MFA coverage.
A SOC or security provider monitors broadly for threats and responds to incidents. IAM is one of the signal sources for this (login events, MFA failures, privilege escalation). We focus on building and integrating the IAM layer itself and ensure the audit logs land in a format your SOC and SIEM can process. In some engagements we work directly with the client's SOC partner to align detection rules with identity signals, such as impossible travel detection, sudden MFA bypass attempts, or unusual patterns in privileged access requests.
Read more
Related topics around IAM, API integrations and the broader security and compliance layer that Appfront builds for Dutch mid-market and enterprise organisations.
Talk to us about your IAM project
Tell us what your identity landscape looks like today: which IdP you use, which applications connect, which compliance requirements apply (NIS2, ISO 27001, NEN 7510, DORA) and where you experience the most friction. We are happy to help with scope, priorities, the choice between packaged and custom solutions, and the design of the federation, MFA and provisioning layer. A no-obligation first conversation will give you a clear picture of the possibilities and the most stable route, whether Entra ID, Okta, Auth0, Keycloak or a custom layer on top.
On applatenmaken.com, our platform on custom software development, you will find a deeper look at building IAM software.