Blog Details


In 2013, during the IAM Summit, Gartner made the prediction, “By 2020, 70% of all businesses will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from 5% today.” Enterprises, for the most part, stuck with the Role Based Access Control. This blog analyses why it is difficult to move beyond RBAC.

  • egisdata
  • 20th Jun 2020

By 2020, 70% of all businesses will use attribute based access control (ABAC) (…)

In 2013, during the IAM Summit, Gartner made the prediction that, “By 2020, 70% of all businesses will use attribute based access control (ABAC) as the dominant mechanism to protect critical assets, up from 5% today.” In April of 2016, the NIST issued a special Publication, cataloged as 1800 with volume 3a, 3b, and 3c. The publication included Executive Summary, Approach, Reference Architecture, Security Characteristics, and How-To Guides. One would think that with Gartner’s predictions and a detailed NIST publication, companies would have implemented ABAC by now, following wide Enterprise adoption. To the contrary, implementations are few and far between. In addition, those that have implemented, struggle with integration, configuration, and maintenance in larger Enterprise settings.

Why is ABAC implementation still a rarity?

To answer this question, first we need to answer why we need ABAC. The predecessor of the ABAC was RBAC, which stands for Role Based Access Control. Role based access control was adequate for environments where protected resources and individuals were cataloged into groups. This method of organization is often referred to as coarse-grained access control. For example, sets of computers located in the subnet could be accessed by groups of individuals working in a department.

Over the last decade, the number of accessed resources such as networks, devices, functions, documents, etc. grew exponentially. Along with a growth in the number of resources, there was a need for tailored access by individuals, rather than by groups. This method of organization is referred to as fined-grained access control. RBAC is not capable of handling access control assignment using the relationship between a single resource and an individual. This gap is bridged by ABAC.

Now that we have justified the need of ABAC, let’s answer the question of why ABAC is still a rarity.

The lack of wide adoption by Enterprises comes from the fact that it is difficult to express business rules defined by humans and translate them into a deterministic policy to be executed by a computer. Application Business Rules have traditionally used the eXtensible Access Control Markup Language (XACML). In 2012, to simplify the schema for XACML, the company Axiomatics developed an Alpha language with direct mapping to XACML. Even though the Alpha was great step up from the complex XACML, the policies still had to be written and audited by developers.

A breakthrough in writing access polices and easy integration with applications.

A group of seasoned security engineers from a startup, EgisData, have developed a new business rules language, Epsilon, and integrated it with Encryption as a Service.  The powerful integration enables access to protected assets, using Policies that can be written by business stakeholders and audited by compliance departments. Further integration with modern Virtual Key Vaults (V-HSM) or traditional Hardware Secured Modules (HSM) adds additional layers of protection through advanced encryption.

Now, you can secure access to individual assets by Digital Identities, further enforced by Policies.

For more information reach out to our specialists at