Hitachi ID Bravura Identity includes a built-in infrastructure to perform periodic certification of users and entitlements.

Access certification is a process where business stake-holders are periodically invited to review entitlements, sign-off on entitlements that appear to be reasonable and flag questionable entitlements for possible removal.

There are several components to access certification:

  • Discovery:

    Before entitlements can be reviewed, they have to be collected from systems and applications and mapped to users. Technical identifiers should be replaced by human-legible descriptions that reviewers will understand. Since entitlements change all the time, discovery should be a regularly scheduled, automated process, not a one-time data load.

  • Who performs the reviews?

    Options include managers -- invited to review their subordinates, application or data owners -- invited to review lists of users who can access their applications or data or security officers -- asked to review high risk entitlements.

  • When are reviews performed?

    The frequency may vary with the business risk posed by the entitlements in question.

  • What kinds of entitlements are reviewed?

    The highest level review is of employment status -- should the user in question still have access to any systems? Slightly more granular is a review of roles -- should the user in question still have these roles? At the lowest level of granularity are basic entitlements -- should the user in question have a login ID on this system or belong to this security group?

  • Which entitlements warrant a review?

    Not every entitlement poses a significant business risk. User membership in the social committee mailing list is not really worth reviewing, for example. Some determination must be made of the risk level posed by each entitlement, as this forms the basis for deciding whether to review it and how often.

  • What happens to revoked entitlements?

    Reviewers may flag entitlements as inappropriate, in which case something should be done. Does this raise a work order in an IT issue management system or trigger a connector to revoke the entitlement immediately? Should further reviews take place before the entitlement is reviewed?

At the highest level, Bravura Identity can be used to review that each user is still affiliated with an organization and that data indicating who the user reports to is correct. This process supports corrections, such as deactivating the user or transferring him to another manager.

Bravura Identity can be used to periodically review security entitlements held by users and, for each entitlement, either certify that it remains appropriate or request that it be removed, perhaps after closer examination by another business user.

This process can be used to certify several kinds of security entitlements which users may have:

  1. Login IDs on directories, systems and applications, which have been associated with a user's profile.
  2. Membership of a user in security groups.
  3. Assignment of roles (which may aggregate other login IDs, groups or roles) to a user.
  4. Previously approved exceptions to segregation of duties (SoD) policies.
  5. Previously approved exceptions to RBAC policies.

The certification process also supports reviews of the configuration of roles and SoD policies (as distinct from who is assigned a role and who has an approval to violate an SoD rule).

Hitachi ID Access Certifier also (uniquely among Identity and access management (IAM) products) supports:

  1. Review/remediation of identity attributes. For example, a manager may update the job code, cost center, etc. of a subordinate.
  2. Bulk onboarding of users, via the same rows-of-users, columns-of-attributes UI.

Finally, the certification workflow and UI can be used to review and correct identity attribute data. Reviewers may be users themselves or people affiliated with them (managers, HR staff, etc.) and are asked to review and correct identity attributes -- location, department, job code, charge code, contact information, etc.

Watch Movies

Review list of subordinates, certify that they still need logins


  • Certify that a list of users are still employed by the organization and each of them still reports to the manager performing the review.

Key concepts:

  • The simplest form of access certification asks “do these people still work here, and report to you?”
  • For each subordinate, the manager can accept (still works for me), revoke (left the organization) or transfer (works for another manager).
  • This type of review is normally hierarchical -- every manager in the organization is asked to review his or her list of direct reports, in a bottom-up sequence.
  • This is a good starting point for access certification.

Review group memberships


  • Review a list of users in a security group.
  • Approve most, revoke one.

Key concepts:

  • Owners of security groups may be periodically invited to review the membership of their groups.
  • They can either accept or reject every group member.
  • When a group member is removed, this triggers a workflow request - with an audit trail and possibly further validation and/or approvals - before the user is actually removed from the group.

Review assigned roles


  • Review a list of users who have been assigned a role.
  • Approve most, remove the role from one.

Key concepts:

  • In principle, any user may be asked to certify role assignment for any list of other users.
  • By default, a resource's owner is assigned to certify the users who have that resource (the resource is a role in this case).

Review approved exceptions to segregation of duties (SoD) policies


  • Review a list of users violate an SoD policy.
  • For each violation, either remove one of the offending security entitlements or create an approved exception.

Key concepts:

  • SoD rules may be expressed in terms of individual entitlements (accounts, group memberships), roles or both.
  • SoD violations must be corrected manually, since the system cannot predict which of several conflicting entitlements should be removed and which are appropriate to the user's needs and should be kept.
  • SoD violations can also be approved, which means that there is a business reason to violate the policy.