Who holds access to what, and the proof it was authorised

Provisioning from role on day one, conflicts blocked before they exist, reviews that produce a record.

Authentication answers whether someone is who they claim. Governance answers whether they should hold this access at all, and whether you can show it was granted, reviewed and revoked correctly. Akku IGA provisions access from someone's role when they join, changes it when their role changes, and removes it across every connected application when they leave. Role combinations you have declared conflicting are blocked at the point of change. Requests route to an approver with the justification attached, and nobody can approve their own. Reviews put entitlements in front of the person accountable for them, and every entry lands in an audit ledger whose integrity is re-verified each time it is read.

What is identity governance and administration?

Identity governance and administration is control over who has access to what, when and why. It covers the automation that grants access as people join and move and removes it when they leave, the model that decides what a role is entitled to, the workflow that approves anything beyond that, and the review that confirms access someone holds is access they should still have.

Akku governs the same identities its authentication runs on, so an entitlement and the sign-in that uses it are not separate records. Provisioning reaches downstream systems over SCIM 2.0, LDAP and Active Directory, Keycloak, REST APIs and a direct database connection where a system supports none of those.

User lifecycle management

Provisioning, re-provisioning and deprovisioning, driven by role.

Birthright access provisioned by role on day one. Re-provisioning when someone changes role or department, so entitlements follow the job rather than accumulating alongside it. And deprovisioning across every connected application at exit, in one action, which is what closes the gap orphan access grows in.

Learn more

Role and attribute-based access control

Roles, attributes, and the combinations you will not allow.

Define what each role and group is entitled to, refined by attribute where a role alone is too coarse. The segregation of duties engine holds the combinations you have declared toxic, and enforcement is graded: a role change or a direct administrative assignment is blocked on a high-severity conflict, while an access request routes to a compliance approver instead of being refused.

Learn more

Access requests and approvals

Anything beyond the role default, requested and signed off.

Self-service requests for access beyond role defaults, through a guided workflow rather than an email. Approval runs manager, then application owner, then a compliance step that joins automatically where the request is higher-risk or carries a conflict. Nobody approves their own request, whether as approver, as administrator, by delegation, or by the chain landing on them. Every request, decision and justification is logged.

Learn more

Access governance and certification

One view of every entitlement, reviewed on a cycle.

Consolidated access shows every user's entitlements across every connected application in one place. Certification campaigns put those entitlements in front of managers and resource owners to certify or revoke, producing a record rather than an assurance. Reconciliation reports accounts that exist with no linked active identity. And SoD violations surface even where the access predates the rule or the conflict is reached through nested roles.

Learn more

A record that can be re-checked rather than trusted

Every governance action lands in an audit ledger where each entry is hash-chained to the one before it. Integrity is re-verified when the ledger is read rather than asserted once at write time, and exports carry the hash columns, so a file handed to an auditor can be independently re-checked.

See how it works.

Provisioning from role on day one, conflicts blocked before they exist, and every governance action on a ledger whose integrity is re-verified each time it is read.

SCIM, LDAP and RESTRBAC and ABAC with SoDTamper-evident audit ledger