What Is IGA? Identity Governance and Administration, Access Review and Entitlement Management

In corporate structures identity and access management is not limited only to enabling users to log in to the system or protecting administrator accounts. An employee's account may have been created correctly, protected with MFA and be accessing corporate applications safely. However, whether the authorities this user has are still necessary is a separate question.

This is exactly the problem IGA – Identity Governance and Administration handles.

IAM manages users' identity verification and access lifecycle. PAM takes high-privilege privileged access under control. IGA, on the other hand, evaluates whether the authorities identities have are really necessary, correct, appropriate and auditable.

For this reason in a modern Identity Security architecture IGA answers this question:

"Does a user really need this access and is this access still correct?"

This question becomes critical especially in large organizations with thousands of employees, hundreds of applications, cloud services, SaaS platforms and a large number of roles.

Because over time users change role, change department, join different projects, receive temporary authorities and start to use new applications. If old accesses are not removed regularly more permission than necessary starts to accumulate on users.

This situation can be called Permission Creep, Privilege Creep or Access Accumulation.

The fundamental aim of IGA is to make this accumulation visible, to reduce the access risk and to keep the organization's authority model continuously under control.

What Is IGA and How Does It Differ from IAM?

Identity Governance and Administration is the body of technology and processes that while managing the lifecycle of identities and access rights at the same time applies governance, compliance and risk controls.

IAM can be thought of as a more operational structure.

For example:

A new employee starts.

An account is opened.

E-mail is given.

SSO is provided.

MFA is activated.

Particular application accesses are assigned.

This process can be managed by IAM.

IGA, on the other hand, afterwards asks this:

Are all of the authorities this user has still necessary?

For example the user may have worked in the Finance department a year ago and gained access to the financial reporting application. Afterwards they moved to the Sales department. New Sales permissions have been added but the Finance access has not been removed.

Technically the user account works correctly.

However, in terms of governance there is a risk.

IGA therefore manages not only access provisioning but the correctness and sustainability of the access.

If we simplify:

IAM → gives access.

IGA → checks whether the access is correct.

PAM → protects high-privilege access more strictly.

These three structures work together inside a modern identity architecture.

Why Is Identity Governance Necessary?

As an organization grows authorities become complex.

In a small company it can be easy for a manager to know which user accesses which application. However, in an organization with thousands of employees a single user can have dozens or hundreds of entitlements.

For example an employee:

Microsoft 365

ERP

CRM

HR Application

File Share

Cloud Storage

Database Reporting

BI Platform

Project Management

VPN

Git Repository

can access systems such as these.

Each of these accesses can contain different permissions.

Read

Write

Export

Admin

Approve

Create

Delete

entitlements such as these can arise.

As the user changes role new permissions are added.

If the old permissions are not removed the risk grows increasingly.

For this reason Identity Governance is not only a compliance need but directly a security requirement.

What Is an Entitlement?

One of the most important concepts in the IGA world is the Entitlement.

An entitlement is the access right or permission an identity has on a particular resource.

For example:

"SAP Finance Read"

"Salesforce Admin"

"SharePoint Confidential Library Access"

"Database Export Permission"

can each be an entitlement.

The total access rights a user has form their entitlement profile.

The duty of IGA is to turn these entitlements into an inventory and to ask these questions:

Who gave this access?

When was it given?

Is there a business justification?

Who is the owner?

For how long is it valid?

Is it still necessary?

What is the risk level?

Without this visibility access governance cannot be applied.

What Is an Access Review?

An Access Review is the process of periodically evaluating whether users' current accesses are still necessary.

For example every three months a manager can be shown their employees' accesses.

The manager:

Approve

Revoke

Modify

can give this decision.

Even though this looks simple in large organizations thousands of access decisions can emerge.

For this reason IGA platforms automate the access review processes.

For example the manager is asked:

"Does Ahmet still need Finance Reporting Access?"

this question.

The manager can approve or revoke the access.

This operation is recorded with an audit trail.

In this way the organization can document the access governance process.

What Is Access Certification?

Access Certification is the access rights users have being formally verified by particular authorized people.

This process is especially important in terms of compliance.

For example:

Financial System Access

Privileged Application Access

Critical Data Access

entitlements such as these can be subjected to certification at particular intervals.

Certification does not have to be carried out only by a manager.

Resource Owner

Application Owner

Data Owner

Security Team

different approvers such as these can be used.

In this way access responsibility is distributed.

Is Manager Review Always Sufficient?

No.

The manager knows what work their employee does but may not know the technical meaning of the permission in the application.

For example:

FIN_AP_47

they see a role in this form.

If the manager does not know what this means the access review can turn into a formality.

For this reason entitlement names must be made business-friendly.

For example:

FIN_AP_47

instead of this:

"Vendor Payment Approval – Level 2"

explanatory naming such as this can be used.

The success of IGA is measured not only by offering an access review screen but by providing the context in which the decision maker can give the correct decision.

Role-Based Access Control and IGA

Inside IGA environments RBAC, that is, Role-Based Access Control, is an important governance model.

Instead of every permission being given to the user separately a role is assigned.

For example:

Finance Analyst

Sales Representative

HR Specialist

Database Administrator

roles such as these can be defined.

Every role contains a particular entitlement set.

In this way provisioning and governance become easier.

However, role design must be done carefully.

Roles that are too broad can give excessive permission.

Too many small roles, on the other hand, can create Role Explosion.

For this reason role engineering and role governance are one of the important areas of IGA.

What Is Role Mining?

Role Mining aims to create role suggestions over similar access patterns by analyzing existing user permissions.

For example in an organization the large part of 150 Sales employees may be using the same 12 application permissions.

IGA analytics by detecting this pattern can suggest that a:

Sales Standard Role

be created.

This enables the access model to be standardized.

However, if the existing permissions are already wrong or excessive role mining can turn this incorrectness into a role.

For this reason role mining results must be reviewed by the business and security teams.

What Is Birthright Access?

Birthright Access is the fundamental access rights the user receives automatically because of their job role or employee type when they join the organization.

For example every employee:

Corporate E-mail

Intranet

Collaboration Platform

Basic HR System

can receive access.

These accesses being given automatically speeds up the onboarding process.

However, birthright permissions must be kept at the minimum level.

Especially sensitive data or privileged actions should not be given as birthright access.

The fundamental approach:

Default Access = Minimum Required

should be this.

What Is Access Request Management?

The user can create a request for the additional access they need.

For example:

"Project X SharePoint Access"

or:

"Financial Reporting Read Access"

they can request these.

The IGA platform can direct the request to the relevant approver over a workflow.

During the approval process:

Business Justification

Manager Approval

Resource Owner Approval

Risk Check

SoD Check

controls such as these can be applied.

This provides a more controlled model than manual e-mail and ticket-based access management.

Should an Access Request Be Time-Limited?

Many access requests are given permanently.

This can create excessive permissions over time.

The safer model is to make access time-bound where possible.

For example:

Project Access = 90 days

External Consultant Access = 30 days

Temporary Finance Role = 14 days

at the end of the period the access can expire automatically.

This approach carries a security principle similar to JIT Access in PAM.

The necessary access should be given only for the necessary period.

What Is Segregation of Duties – SoD?

Segregation of Duties aims to prevent a critical business process being controlled completely by a single person.

For example inside a financial process the same user having the permissions:

Vendor Create

and

Payment Approve

can increase the fraud risk.

These two entitlements can be normal separately.

However, together they create risk.

The IGA platform can detect these toxic combination relationships.

When during an access request the user requests a new role the system can check whether there is a conflict with the existing permissions.

In this way an SoD violation can be prevented before the access is given.

What Is a Toxic Combination?

A Toxic Combination is separately acceptable permissions creating a high risk when used together.

For example:

Create User

Assign Administrator Role

the combination can be high-risk.

Another example:

Create Vendor

Approve Payment

or:

Create Purchase Order

Approve Purchase Order

can be these.

One of the important capabilities of IGA is to make these relationships visible.

Because when only the permission list is looked at the risk may not be noticed.

Preventive and Detective SoD

SoD can be applied in two different ways.

Preventive SoD blocks the access request before the risky permission combination arises.

For example if the user is a Payment Approver the Vendor Creator role request is blocked.

Detective SoD, on the other hand, detects the conflicts present on the existing systems.

For example a toxic combination left over from the past is reported and remediation is started.

A mature IGA architecture can use the two approaches together.

How Does Permission Creep Arise?

Permission Creep mostly does not arise as the result of a malicious operation.

It is the natural result of organizational changes.

The employee starts work.

They receive access to five applications.

Six months later they join a new project.

Three new permissions are added.

A year later they change role.

Seven more permissions are added for the new role.

A part of the old permissions is not removed.

Three years later a far broader access footprint than the user's real duty arises.

This situation enlarges the impact when the attacker compromises the account.

Therefore the security benefit of IGA is not only compliance.

It provides Compromise Impact Reduction.

The Relationship Between Joiner-Mover-Leaver and IGA

IAM can automate the Joiner-Mover-Leaver process.

However, IGA strengthens the governance part of this lifecycle.

At the joiner stage role-based birthright access can be given.

At the mover stage the old permissions can be reviewed automatically.

At the leaver stage all entitlements can be revoked.

The Mover process in particular is of critical importance.

Because the account of a user who changes role inside the organization is not closed.

For this reason the old access can easily be forgotten.

IGA using the mover event as a trigger can carry out:

Current Access Review

Old Role Removal

New Role Assignment

SoD Check

these.

This reduces access accumulation.

What Is Orphaned Access?

Similarly to the Orphaned Account concept, there can also be access rights whose owner or business need no longer exists.

For example the project has ended but the project group permissions are still present on the users.

The application owner has changed and what the entitlement is for is no longer known.

This situation can turn into an orphaned entitlement or unmanaged access problem.

IGA reduces this risk with regular access review and entitlement ownership.

Why Is the Entitlement Owner Important?

Determining a business owner for every sensitive access right is important in terms of governance.

The security team may not know the business impact of every application permission.

For example:

"Refund Approval Level 3"

the Finance process owner knows better to whom this permission should be given.

IGA therefore does not leave access responsibility only on IT.

It creates business ownership.

This is one of the most important cultural transformations of access governance.

How Do IGA and Privileged Access Work Together?

PAM controls how privileged access will be used.

IGA, on the other hand, governs on whom this privileged access should be present.

For example the user:

Database Administrator Role

can be eligible for this.

IGA:

Does this user have a business requirement to have the role?

Is there an SoD conflict?

Has an access review been carried out?

manages these questions.

PAM, on the other hand:

When will the role be activated?

Was MFA applied?

Will the session be recorded?

When will the privilege expire?

manages these questions.

When these two layers work together stronger privileged identity governance is provided.

The Relationship Between IGA and Cloud IAM

Cloud environments can seriously increase the number of entitlements.

Platforms such as AWS, Azure and Google Cloud offer granular permission models.

A single cloud identity can have hundreds of action permissions.

This situation makes access governance harder.

IGA can take cloud identities and roles into the governance scope.

However, for cloud permission optimization CIEM capabilities can also be necessary.

IGA focuses more on:

Who should have which access?

while CIEM:

Which permissions are really used on the cloud and which are unnecessary?

can give a deeper answer to this question.

For this reason inside a modern Identity Security Architecture IGA and CIEM complement each other.

The Difference Between IGA and CIEM

IGA focuses on identity governance across the organization.

Human identities, applications and enterprise entitlements can be managed.

CIEM, on the other hand, provides visibility and optimization especially on cloud infrastructure entitlements.

For example a cloud role contains 150 permissions but the user has used only 8 permissions in the last 90 days.

CIEM can detect this excessive permission.

IGA, on the other hand, can evaluate whether this role being assigned to the user is appropriate as a business matter.

These two perspectives together strengthen the Least Privilege approach.

IGA and Non-Human Identity

IGA has traditionally concentrated on human workforce identities.

However, inside modern organizations service accounts, bots, workloads and AI Agents are using increasingly more access.

Governance is necessary for these identities too.

For example for a service account:

By whom was it created?

Who is the owner?

Which application uses it?

Which permissions does it have?

For how long has it been active?

Is it still necessary?

These questions are as important for an NHI as they are for a human identity.

For this reason the scope of modern Identity Governance:

Human Identity Governance

from this model:

Human + Machine Identity Governance

is broadening towards this model.

AI Agent Governance and IGA

Agentic AI is bringing out a new governance problem in terms of IGA.

An AI Agent can access applications on behalf of the user.

It can change a CRM record.

It can read a file.

It can use an API.

It can start a financial workflow.

In this case the entitlements given to the agent must also be taken into the governance scope.

For example:

On behalf of which user is the agent working?

Does the agent have its own identity?

Which applications can it access?

Which actions can it carry out?

Is the permission permanent?

Who is the business owner?

Is approval necessary?

Is an audit trail being kept?

The answers to these questions will form the AI Identity Governance model of the future.

While giving permission to an AI Agent traditional RBAC may not be sufficient on its own.

Context-aware and task-specific authorization can be necessary.

For example the agent:

"invoice read"

can carry this out but:

"payment approve"

cannot carry this out.

This fine-grained authorization and governance approach is one of the newly developing areas of Identity Security.

What Is Risk-Based Access Review?

Traditional access review cycles can be the same for all users.

For example once a year all accesses are reviewed.

However, this approach may not be sufficient for high-risk permissions.

In the Risk-Based Access Review approach the review frequency changes according to the risk level of the entitlement.

For example:

Low Risk Access → Annual Review

Sensitive Data Access → Quarterly Review

Privileged Access → Monthly or Event-Based Review

can be applied.

This enables security resources to focus on critical accesses.

Event-Driven Access Review

Modern IGA does not have to be limited only to calendar-based certification.

Particular events can trigger a review.

For example:

Department Change

Manager Change

High-Risk Sign-In

New Privileged Role

Long Dormancy

Project Completion

when these take place an access review can be started automatically.

This is the transition from a static governance model to a dynamic governance model.

Usage-Based Access Governance

An entitlement a user has can have been active for years but may never be used.

In this case this question should be asked:

Why does unused access stay open?

When usage analytics is integrated with IGA unused access rights can be detected.

For example if the user has not logged in to the application for 180 days an access certification can be triggered.

This makes the Least Privilege approach more data-driven.

AI-Supported Role Mining and Access Recommendation

Modern IGA platforms can create suggestions about access decisions using analytics and machine learning.

For example while the large part of employees in a similar role has a particular application access, if a new employee does not have the access a recommendation can be created.

In the opposite case it can be detected that the user has unusual permissions compared to their peers.

This is the Peer Group Analysis and Access Intelligence approach.

However, an AI recommendation should not be seen as the final authorization decision.

Especially for high-risk access human governance must be preserved.

AI:

Decision Support

should provide this,

it should not produce broad privilege automatically.

What Is Access Intelligence?

Access Intelligence aims to create more meaningful context about access by analyzing identity, entitlement, usage and risk data.

For example the user having a permission gives information on its own.

However, when the following information is evaluated together a stronger insight arises:

What is the user's role?

Do peers have this permission?

For how long has the permission not been used?

Is it a sensitive resource?

Does it create an SoD conflict?

Is the user a high-risk identity?

This context can increase the quality of the access review.

Which Functions Do IGA Platforms Provide?

Corporate IGA platforms can generally be positioned around these capabilities:

Identity Lifecycle Governance

Access Request

Access Certification

Role Management

Entitlement Management

SoD

Access Analytics

Automated Provisioning

Policy Enforcement

areas such as these.

Platforms such as SailPoint, Saviynt and One Identity are among the known solutions for enterprise Identity Governance use cases.

However, the product choice should not be made only over a feature comparison.

Especially:

application integration,

entitlement volume,

identity count,

workflow complexity,

cloud strategy,

PAM integration,

HR integration,

custom applications

architecture requirements such as these must be evaluated.

The hardest part of an IGA project is most of the time not installing the product but making the organization's scattered entitlement model meaningful and manageable.

How Are SailPoint, Saviynt and One Identity Positioned?

SailPoint is one of the platforms widely associated in the enterprise identity governance area with use cases such as access certification, lifecycle, entitlement governance and role-based governance.

Saviynt can be evaluated with cloud-oriented identity governance and application entitlement governance use cases.

One Identity, on the other hand, has a product family that offers different identity security capabilities including identity governance and privileged access.

Which of these products is suitable:

on-premises and cloud distribution,

the application landscape,

ERP integration,

workflow requirements,

the PAM ecosystem,

identity volume

can change according to factors such as these.

The aim here is not to carry out vendor ranking but to understand the product category of IGA.

How Should an IGA Project Be Started?

The first step of a successful IGA project should not be connecting all applications to the governance platform at one go.

First high-risk business systems can be determined.

For example:

ERP

Financial Applications

HR

Critical Databases

Privileged Systems

can be prioritized.

Afterwards an entitlement inventory is created.

Permissions are defined with business-friendly names.

Owners are determined.

Access review workflows are designed.

SoD rules are created.

A role model is developed.

In this way IGA is expanded gradually.

Why Is IGA and HR Integration Important?

The HR system can for most organizations be the authoritative source of the workforce identity lifecycle.

When a new employee is created in HR the Joiner process starts.

When the department changes the Mover process is triggered.

When a termination takes place the Leaver process is started.

For this reason IGA and HR integration provides strong lifecycle governance.

However, the accuracy of the HR data is critical.

Wrong department or manager information can cause wrong access decisions.

For this reason Identity Governance is at the same time a data quality problem.

What Is Access Review Fatigue?

When hundreds of entitlements are sent to a manager it becomes harder for them to review each one carefully.

The user can quickly carry out:

Approve All

this.

This can be thought of as Access Review Fatigue.

If the review process produces too much noise governance turns into a formality.

For this reason intelligent scoping must be applied.

Especially:

High-Risk Access

Unusual Access

Unused Access

SoD Conflicts

Privileged Access

can be prioritized.

Low-risk standard birthright permissions can be managed with a separate process.

In this way the review quality is raised.

The Rubber-Stamp Approval Risk

The other important risk in the access review process is Rubber-Stamp Approval.

The reviewer can continuously approve without understanding all of the entitlements.

To prevent this:

Business-friendly descriptions,

risk scores,

usage information,

peer comparison,

the last access date

context such as this can be shown.

For example if the reviewer sees this information:

"This user has not used this access for 14 months."

it can become easier for them to give a revoke decision.

IGA and Compliance

IGA also provides value in terms of many regulatory and compliance requirements.

Organizations can be obliged to show who accesses particular systems, by whom the access was approved and when it was reviewed.

IGA creates an audit trail for these processes.

However, IGA should not be seen only as a compliance tool to be used during an audit.

When applied correctly it reduces the attack surface.

Because unnecessary access being removed limits the resources the attacker can reach over a compromised identity.

Least Privilege and IGA

Least Privilege is not only related to PAM.

It must be applied for normal workforce users too.

The access necessary for the user to do their work must be given and unnecessary permissions must be removed.

IGA makes this principle continuous.

At the beginning minimum access is given.

Over time changes are reviewed.

Unused access is removed.

High-risk entitlements are taken into certification more frequently.

In this way Least Privilege becomes not a one-off configuration but a continuous governance process.

The Relationship Between Zero Trust and IGA

Zero Trust is not only verifying the user and device during authentication.

The authorization also needs to be continuously correct.

The user can be the correct identity but can have the wrong privilege.

In this case even if the authentication is strong the security risk continues.

For this reason for Zero Trust:

Verify Identity

as much as this:

Verify Entitlement

is also important.

IGA provides this second layer.

The modern Zero Trust authorization model:

Identity + Device + Risk + Entitlement + Context

must be evaluated together.

IGA and SOC Integration

IGA is traditionally seen as a governance platform.

However, it also provides valuable context for the SOC.

For example the SIEM detected suspicious user activity.

The SOC can want to see this information:

Which applications can the user access?

Are there privileged roles?

Do they have sensitive data access?

Are there SoD conflicts?

Is there a recent access change?

IGA can provide this entitlement context.

In this way the incident severity can be evaluated more correctly.

IGA and ITDR Integration

When ITDR detects risky identity behavior IGA can trigger an access review.

For example unusual privileged activity was detected on the user.

The system:

Emergency Access Review

can start this.

High-risk entitlements can be suspended temporarily.

This is the important point at which governance and threat detection merge in the Identity Security Architecture of the future.

The model:

Detect Risk → Re-Evaluate Access → Reduce Entitlement

can be in this way.

How Are IGA KPIs Determined?

An IGA programme should not be measured only by how many access reviews were completed.

More meaningful KPIs can be used:

Access Review Completion Rate

Revoked Access Ratio

Unused Access Reduction

Orphaned Entitlement Count

SoD Violation Count

Mover Access Cleanup Rate

Leaver Deprovisioning Completion

High-Risk Access Review Frequency

Time-Bound Access Ratio

Role Coverage

indicators such as these can be used.

Especially:

Access Review Completion = 100%

being this is not success on its own.

If all reviewers are approving everything real governance has not arisen.

The more important metric:

Is unnecessary access really being reduced as a result of the review?

should be this.

The Most Frequently Made Mistakes in IGA

The mistakes frequently seen in corporate IGA projects are these:

• Seeing IGA only as a compliance tool
• Not creating an entitlement inventory
• Leaving permission names incomprehensible for the business
• Not determining a resource owner
• Carrying out Access Reviews once a year as a formality
• Sending the reviewer more access than necessary
• Not monitoring Rubber-Stamp Approval
• Not measuring Permission Creep
• Leaving the mover process outside governance
• Not defining SoD rules
• Not analyzing Toxic Combinations
• Defining Birthright Access more broadly than necessary
• Giving Temporary Access permanently
• Not removing Unused Access
• Not taking Service Accounts into the governance scope
• Leaving Cloud Entitlements outside
• Managing PAM and IGA as separate silos
• Leaving AI Agent permissions outside governance
• Ignoring HR data quality problems
• Accepting access review completion as the single success metric

IGA Security Checklist

Organizations can evaluate their Identity Governance maturity using the following controls:

• Is an Entitlement Inventory present?
• Are the business owners of applications known?
• Have sensitive permissions been classified?
• Is an Access Request workflow being used?
• Is business justification mandatory?
• Are access approvals being recorded?
• Is Birthright Access at the minimum level?
• Is RBAC being applied?
• Is Role Mining being carried out?
• Is Role Explosion being controlled?
• Are Access Reviews carried out regularly?
• Is High-Risk Access reviewed more frequently?
• Is Access Certification being applied?
• Are unused permissions being detected?
• Is dormant access being removed?
• Does the mover process remove the old permissions?
• Does the leaver process revoke all entitlements?
• Does Temporary Access use expiry?
• Is External User access time-limited?
• Are SoD policies defined?
• Are Toxic Combinations being detected?
• Is Privileged Access being taken into the IGA governance scope?
• Are IGA and PAM integrated?
• Are Cloud Entitlements being taken into the governance scope?
• Is an owner defined for Service Accounts?
• Are Non-Human Identities being taken into the governance scope?
• Are AI Agent permissions recorded?
• Is usage data shown during the Access Review?
• Is Peer Group Analysis being used?
• Are IGA logs accessible for the SIEM/SOC?
• Can an emergency review be carried out after a risk event?

IGA Maturity Model

Level 1 – Manual Authority Management: Access requests are made by e-mail or ticket. There is no central inventory of permissions. It is hard to see what users access.

Level 2 – Central Access Review: For critical applications an entitlement inventory and periodic access certification are applied. Manager reviews start.

Level 3 – Automated Governance: Joiner-Mover-Leaver, Access Request, SoD and Role-Based Governance become automated. Temporary access and business ownership become widespread.

Level 4 – Risk-Based Identity Governance: High-risk, unused and unusual permissions are detected with analytics. The review frequency changes according to the access risk. IGA, PAM and cloud entitlement management work together.

Level 5 – Continuous Adaptive Governance: Human, Machine and AI Agent identities are subjected to continuous entitlement evaluation. Access decisions are re-evaluated with usage, risk, peer analysis and real-time identity signals.

This transformation:

Manual Access Management

↓

Periodic Certification

↓

Automated Governance

↓

Risk-Based Governance

↓

Continuous Identity Governance

proceeds in this way.

Frequently Asked Questions

What is IGA?

IGA, Identity Governance and Administration, is the body of technology and processes that manages the lifecycle, correctness, risk and governance processes of the access rights users and other identities have.

What is the difference between IAM and IGA?

While IAM manages identity authentication and the access lifecycle, IGA governs whether the access given is still necessary and appropriate.

What is the difference between PAM and IGA?

PAM controls the safe use of privileged access. IGA, on the other hand, manages whether the user having this privileged access is appropriate as a business matter.

What is an Access Review?

It is the evaluation at particular intervals or after a risk event of whether users' current permissions are still necessary.

What is Access Certification?

It is the process of access rights being formally approved or removed by an authorized reviewer.

What is an Entitlement?

It is the permission or access right an identity has on a particular resource.

What is Permission Creep?

It is the user accumulating more access than necessary as a result of acquiring new permissions without losing the old permissions because of role and project changes over time.

What is SoD?

Segregation of Duties is the principle of separation of duties that provides for all the steps of a critical process not to be able to be carried out by the same user.

What is a Toxic Combination?

It is a permission combination that is separately acceptable but creates a high risk when used together.

What is Birthright Access?

It is the fundamental access rights the user receives automatically because of their job role or employee type when they start work.

What is Role Mining?

It is the method that supports appropriate business roles being created by analyzing existing user permissions and access patterns.

Are IGA and CIEM the same thing?

No. While IGA focuses on identity governance across the organization, CIEM concentrates especially on cloud infrastructure permissions and excessive entitlements.

Should Service Accounts be within the scope of IGA?

Yes. If a service account uses high privilege or sensitive access its owner, business purpose and permissions must be governed regularly.

Should AI Agent permissions be taken into the scope of IGA?

If an AI Agent can carry out actions on applications and data it must be taken into the scope of identity and entitlement governance. Which authorities the agent has, for which purpose it uses them and who its owner is must be determined.

What kind of products are SailPoint and Saviynt?

They are IGA platforms used for enterprise Identity Governance and Administration use cases. They can provide capabilities such as access certification, lifecycle governance, entitlement management and role governance.

Is carrying out an Access Review once a year sufficient?

The same frequency is not appropriate for every access. For sensitive or privileged access more frequent or event-driven review can be applied.

Conclusion: Verifying the Identity Is Not Enough, the Authority Must Also Be Verified Continuously

Inside modern Identity Security strong authentication is extremely important.

You can use SSO.

You can apply MFA.

You can use a passkey.

You can provide phishing-resistant authentication.

However, if a user who carries out authentication correctly has the wrong permissions the security problem continues.

For this reason:

Strong Authentication ≠ Correct Authorization

IAM enables the identity to reach the system safely.

PAM enables high privilege to be used safely.

IGA, on the other hand, continuously questions whether the access the identity has is correct.

That is why the question at the centre of IGA:

"Has the user received this access?"

is not this,

"Does the user still need this access today?"

it should be this.

The modern governance model should not rest only on periodic access certification.

As cloud, hybrid work, SaaS and Non-Human Identity adoption increases access relationships are continuously changing.

For this reason Identity Governance too:

Periodic

from this model:

Continuous

is evolving towards this model.

The IGA architecture of the future:

the identity lifecycle,

Access Usage,

Risk Signals,

Peer Group Analytics,

Cloud Entitlements,

Privileged Access,

Machine Identity

and AI Agent permissions

will have to evaluate this data together.

The fundamental formula of this approach:

Know the Identity → Know the Entitlement → Know the Business Need → Know the Risk → Remove What Is Not Needed

can be summarized in this way.

In shorter expression:

As much as giving the right authority to the right identity, removing on time the authority that is no longer necessary is also part of security.

And the most important sentence of this chapter:

The real success of modern Identity Governance should be measured not by how many accesses were approved but by how quickly unnecessary, unused and risky authorities in the organization are detected and removed.