How to Choose an IAM Solution Before You Sign a Contract

Here is how to choose an IAM solution, map the users and applications you need to protect, then test each candidate with real scenarios before you sign a contract. An IAM (identity and access management) system controls who can sign in to which application, and a poor choice becomes obvious when a former employee’s access is never revoked.

According to ENISA Threat Landscape 2025, phishing was the initial intrusion vector in about 60% of the cases the EU cybersecurity agency observed between July 2024 and June 2025. Phishing often targets passwords and login sessions, so your IAM platform helps decide whether an attacker can use stolen credentials right away.

This article covers seven key criteria for an IAM platform and six steps to choose one, along with a sample scoring matrix for comparing vendors.

Key Criteria for Choosing an IAM Solution

The key criteria for choosing an IAM solution are integration, phishing-resistant authentication, access lifecycle automation, audit logs, vendor data security, availability, and ease of use. All seven decide whether a platform can secure access without adding manual work for your IT team.

Integration with Existing Systems

An IAM platform is only useful if it connects to the applications and employee data sources you already use. Check every candidate for these capabilities:

• Sync with your HR information system (HRIS) as the source of employee data, so accounts are created and disabled to match employment status.
• Support for Active Directory or LDAP, the directory services that store user accounts on local servers, if your company still runs them.
• Support for SAML 2.0 and OpenID Connect (OIDC), the two standard protocols for connecting SSO (single sign-on, one login for all work applications) to your applications.
• Support for SCIM, a standard for creating, updating, and deleting user accounts in other applications automatically.
• A way to handle legacy applications that do not support SAML or OIDC, such as an installed agent or an API-based connector.

Applications without SCIM support can still use SSO, but admins may have to create and remove their accounts by hand.

Phishing-Resistant Authentication

Not every form of MFA (multi-factor authentication, which verifies users with two or more factors) resists phishing. Victims can still type one-time passcodes (OTPs) from SMS or an authenticator app into a fake login page, and they can approve push notifications without suspecting anything.

NIST SP 800-63B-4, the US federal guideline on authentication, requires systems at assurance level AAL2 (two factors) to offer at least one phishing-resistant option. That option is usually a passkey or FIDO2/WebAuthn security key, whose cryptographic key on the user’s device works only with the genuine domain, never a fake site.

Also check for these capabilities:

• Passkey and security key support for all users, with the option to require them for admin accounts.
• Conditional access that evaluates the device, location, time of access, and risk level before allowing a sign-in.
• A secure account recovery flow for users who lose their phone. Attackers can exploit a weak flow by posing as employees when they contact the helpdesk.

If a vendor offers biometric login, find out where biometric matching takes place. NIST prefers local matching on the user’s device over central matching on a server.

Under Article 4(2) of Indonesia’s Personal Data Protection Law (UU PDP), Law No. 27 of 2022, biometric data counts as specific personal data, the law’s sensitive category. Unlike a password, it cannot be changed after a leak.

Access Lifecycle Automation

The access lifecycle covers three events: an employee joins, changes roles, or leaves. The right platform grants access by role (role-based access control, or RBAC) and updates it automatically when the HR record changes, with no IT ticket needed.

Role changes are the easiest event to miss. A transferred employee stays active, but access from the old role can carry over and pile up without automation, a problem known as privilege creep.

Offboarding must remove access from every application, including those outside email and the main directory. An account left active after its owner departs becomes an orphaned account: it has no legitimate owner, and attackers can use it without being noticed.

HR-driven automation misses service accounts, which applications use to talk to each other, because those accounts never appear in the HR system. Choose a platform that can record an owner and an expiry date for every service and integration account.

Audit Logs and Access Reports

The right IAM platform logs every sign-in and access change, then turns them into ready-made reports on who has access to which application. These records help you meet Article 31 of UU PDP, which requires companies, as data controllers, to record all personal data processing activities.

Check how long the vendor keeps logs and whether you can export them or forward them to your SIEM (security information and event management) system.

If auditors regularly ask for evidence of access reviews, the periodic checks that confirm each person still needs their access, see whether the platform includes this feature. Without it, you will need a separate identity governance and administration (IGA) module.

Vendor Data Security and Data Residency

An IAM vendor processing employee data on your behalf is a data processor, so Article 52 of UU PDP extends the security duties in Articles 35 and 39 to it. Ask for proof, such as an ISO/IEC 27001 certificate (the international standard for information security management) and the list of services it covers.

For cloud platforms, ask which countries store and process user data. If the data leaves Indonesia, Article 56 requires you to make sure the destination country protects data at a level equal to or higher than UU PDP.

If it does not, you must ensure adequate and binding safeguards are in place, and if those are missing too, you must obtain consent from the data subjects.

Availability, Scalability, and Emergency Access

Your IAM platform is the front door to every application, and an outage can stop all employees from working at once. Ask how the vendor keeps the service running (for example, a backup data center in another region) and request its outage history for the past year.

Make sure the platform supports emergency break-glass accounts, the backup admin accounts you use to sign in when the IAM service is down. The platform should send an alert whenever someone signs in with one.

If your company is growing, check each plan’s limits on users, applications, and sign-in requests per minute. Limits set too low can throttle sign-ins at peak hours or push you into a pricier plan early.

Ease of Use for Users and Admins

A clumsy login flow pushes employees toward shortcuts, such as saving passwords in a phone note or reusing one password for every account. Choose a platform with a single app portal and self-service password reset, so employees do not have to wait for the helpdesk.

On the admin side, you should be able to set access policies in the interface without writing code and split admin duties by division or location. An interface in your staff’s language (Bahasa Indonesia for teams in Indonesia) and clear documentation make internal training faster.

6 Steps to Choose an IAM Platform

Choosing an IAM solution takes six steps: map your needs, set must-have criteria, shortlist vendors, test the candidates, calculate total cost, and lock vendor commitments into the contract. Steps 2 to 4 use the seven criteria above as their yardstick.

1. Map Your Users, Applications, and Current Problems

Build an inventory before you contact any vendor. This list is the basis for every later evaluation, and it should cover at least the following:

• User groups, including permanent employees, contractors, vendors, and service accounts.
• A list of SaaS applications (subscription cloud software), applications hosted on your own servers (on-premises), and in-house applications, with the login method for each.
• Your main problems today, such as new hire accounts that take days to set up or password reset tickets that keep piling up.

Next, flag high-risk applications, meaning those that store customer or financial data and those that grant administrator access. Include these applications in your later tests alongside the popular SaaS apps that already have vendor-built connectors.

2. Set Must-Have Criteria Based on Problems and Regulations

Decide which criteria are must-haves before you watch any vendor demo, so the most impressive feature in a presentation does not sway your assessment. Must-have criteria come from two sources: the problems in your step 1 inventory and the rules your company must follow.

If your biggest problem is slow access removal for departing employees, HRIS integration and access lifecycle automation belong on the must-have list. On the regulatory side, Article 39 of UU PDP requires any company processing personal data, including employee data in an IAM platform, to prevent unauthorized access.

That obligation is reason enough to add phishing-resistant authentication and audit logs to your must-have list.

Commercial banks and payment system operators face extra obligations under the MFA requirements set by the Financial Services Authority (OJK) and Bank Indonesia, the central bank. In these sectors, and in any sector that handles specific personal data such as health data, make vendor data security and residency a must-have as well.

3. Narrow the Vendors Down to a Shortlist

Turn the seven key criteria into the same written questionnaire for every vendor, and ask for answers backed by documents such as an official connector list and security certificates. Vendors that cannot prove the must-have criteria in writing do not move on to the next stage.

For the two or three candidates left, contact reference customers whose user count and industry resemble yours. Talk to them without the vendor present, and ask whether automatic access removal actually works in their legacy applications.

4. Run a Proof of Concept with Real Scenarios

A proof of concept (PoC) is a limited trial of a candidate platform in your own environment. Run the same scenarios for every shortlisted candidate so you can compare the results.

Vendor demos usually show only SSO to popular SaaS apps. That is why you should test at least these five scenarios:

1. Sign in with SSO to one high-risk application and one legacy application that does not support SAML.
2. Deactivate a test employee in the HR system, then record how long it takes for their access to disappear from each test application.
3. Move a test employee to another division, then check whether access from the old division is removed.
4. Recover the account of a user who has lost their phone or security key.
5. Pull a report of who accessed which application during the trial, in a format your auditors accept.

Involve HR and application owners in the PoC, since they feel the results of access automation directly. Use the same trial period to assess vendor support, such as response times on technical tickets and whether the support team covers your time zone.

5. Calculate Total Cost of Ownership for at Least Three Years

The per-user license price is only part of what an IAM platform costs. Calculate the total cost of ownership (TCO) for at least three years and include these components:

• Licenses and add-on modules, such as advanced MFA or premium connectors.
• Implementation services, including legacy application integration and user data migration.
• Authentication hardware, such as security keys for admin accounts.
• Internal staff time to manage the platform and train users.
• Exit costs, meaning the effort to move configurations and data if you ever switch vendors.

Compare every quote using the same number of users and the same application scope, so the price gaps reflect real differences.

6. Lock Vendor Commitments into the Contract

What a vendor promises in a demo or PoC is binding only once it is in the contract. Write the uptime target and support response times into a service level agreement (SLA), with compensation if the vendor misses them.

Also include a data protection clause that lists subprocessors, because Article 51(5) of UU PDP requires a processor to get your written approval before bringing in another processor.

Finally, agree on an exit plan: the export format for user data and audit logs, such as CSV or JSON, and a post-contract deadline for deleting your data. Without one, you risk vendor lock-in.

Sample IAM Platform Scoring Matrix

A scoring matrix turns the key criteria, PoC results, and TCO calculations into numbers you can compare across vendors. Give a weight of 3 to must-have criteria, 2 to important criteria, and 1 to nice-to-haves, then score each from 1 to 5 based on the evidence you collected.

Each vendor’s final score is the sum of weight times score across all criteria.

Criterion	Weight	How to test	Evidence to request from the vendor
Integration with existing systems	3	Connect the HRIS and two priority applications during the PoC	Test results and the official connector list
Phishing-resistant authentication	3	Sign in as an admin with a passkey or security key	FIDO2 support documentation and the MFA enforcement policy
Access lifecycle automation	3	Deactivate and transfer a test employee in the HRIS	Time records of access changes in each application
Audit logs and access reports	3	Pull an access report for the PoC period	Sample reports and the log retention period
Vendor data security and data residency	2	Check data center locations and certificate scope	Data location documents, security certificates, and the subprocessor list
Availability, scalability, and emergency access	2	Test sign-in with a break-glass account	Outage history, backup data center plan, and plan limits
Ease of use	2	Have 10 employees from different divisions use SSO for one week	Short survey results and the number of help tickets
Three-year TCO	2	Build a cost simulation with the vendor	Breakdown of licenses, implementation, and exit costs
Vendor support	2	Submit a technical ticket during the PoC	Response times and a written SLA
Extra features and product roadmap	1	Review features beyond your current needs	Feature demo and product roadmap document

Adjust the weights to match the must-have criteria you set in step 2, then treat every criterion weighted 3 as a pass/fail gate. Drop any vendor that scores 1 or 2 on one of those criteria, even if its total is high.

Base the scores on PoC results and the vendor’s written answers, not on impressions from the demo. Keep the matrix and its evidence so you can answer auditor questions about why you chose the vendor.

Read also: 10 Best IAM Solution Recommendations in 2026

Conclusion

The best IAM platform for your company is the one that passes testing with your own applications and compliance obligations, not the one with the longest feature list. Treat HRIS integration, phishing-resistant MFA, automatic access removal, and audit logs as non-negotiable.

Start this week by building an inventory of your applications, their login methods, and their owners. That list becomes the basis for your scoring matrix and PoC scenarios when you contact vendors.

FAQ