Role based access control (RBAC) is a way of managing permissions in which you grant rights to roles, such as "installer" or "viewer", and then assign people to those roles, instead of granting every right to every person one at a time. When someone changes jobs, you change their role, and the permissions follow automatically.

That sounds like a back-office IT detail until the system in question controls physical equipment. In a connected building or plant, the login that opens a temperature chart might also be able to edit an automation, delete a device or send a command to a valve. Who holds which of those rights is a safety decision as much as a security one, and it gets harder with every colleague, contractor and customer you invite.

In short

  • RBAC groups permissions into roles and assigns people to roles, so access stays manageable as a team grows.
  • Least privilege means every person and every integration gets only the rights its job needs, starting from nothing.
  • In connected systems, the risky permissions are the ones that change things: automations, device settings and commands.
  • A multi-tenant platform adds an outer boundary that keeps each customer's data out of sight of the others.

Role based access control examples

The model is easiest to see on a real-looking deployment. Take a service company that monitors 40 office buildings with temperature, leak and door sensors. Five kinds of people need access, and each needs something different. Written down as roles, it could look like this:

Role Devices Dashboards Automations and alarms Device commands Users and billing
Installer Edit View None Send None
Facility manager View Edit Edit Send None
Tenant contact None View, own building only None None None
Support engineer Edit Edit Edit Send None
Account owner Edit Edit Edit Send Edit

That table is the whole idea of RBAC. Instead of maintaining dozens of individual permission lists, you maintain five rows. A new installer gets the Installer role on day one and can register hardware without touching billing. When the installer moves on, removing that one role removes everything at once, which avoids a familiar problem: accounts that outlive the job they were created for.

The approach has a documented history. David Ferraiolo and Richard Kuhn of the US National Institute of Standards and Technology (NIST) described role-based access control in 1992, and a unified NIST model later became the ANSI INCITS 359-2004 standard. NIST describes RBAC as the predominant model for advanced access control, and many implementations add role hierarchies, where a senior role inherits everything a junior role can do.

Look again at the Tenant contact row, though. "Own building only" doesn't fit neatly into a role. With 40 buildings, pure RBAC pushes you toward 40 roles: Tenant contact for Building 1, Tenant contact for Building 2, and so on. Administrators call this role explosion, and it's the main reason access models have moved beyond roles alone, as the comparison further down explains.

What is the principle of least privilege?

The principle of least privilege says that every user and every program should operate with the smallest set of permissions that lets it do its job. Jerome Saltzer and Michael Schroeder put it into those terms in their 1975 paper on protecting information in computer systems, and it has been a design principle ever since.

Roles organize permissions, and least privilege decides how big each role should be. An "Operator" role that also includes deleting devices follows the RBAC model but grants more than an operator's work requires.

The principle matters more than usual for connected equipment because permissions come in three distinct strengths. Reading data is the mildest. Changing configuration, such as a threshold or an automation, is stronger, because a wrong edit can hide a real problem. Sending commands is the strongest, because it moves something in the physical world. A good role design keeps these three apart, so that most people read, fewer people configure, and only the people who need to act can send commands.

Least privilege applies to machines too. Consider a reporting script that copies yesterday's sensor readings into a spreadsheet every morning. If it runs with an administrator's credentials and that token leaks into a shared code repository, whoever finds it can change automations and send commands. If it runs with a read-only key limited to readings, the same leak exposes data but can't touch the equipment.

The OWASP Top 10, the best-known ranking of web application security risks, put broken access control in first place in its 2021 edition and kept it there in the 2025 edition. IoT platforms are web applications, so the lesson carries over directly.

To apply least privilege to a deployment that already exists, you can work through it in this order:

  1. List every human account and every integration credential, including the ones nobody remembers creating.
  2. Write one sentence describing what each one is for.
  3. Remove every permission that sentence doesn't require.
  4. Separate read, configure and command rights wherever the software allows it.
  5. Give contractor accounts and integration keys an end date.
  6. Repeat the review on a fixed cadence, for example every quarter, and whenever a project or contract ends.

Role based access control vs attribute based access control

Attribute-based access control (ABAC) makes each decision from attributes of the user, the resource, the action and sometimes the environment, rather than from a role alone. NIST's guide to ABAC, Special Publication 800-162, was published in 2014. A typical ABAC policy reads like a sentence: "a tenant contact may view dashboards for the building listed on their profile." One policy replaces the 40 tenant roles from the earlier example.

The trade-off is visibility. With RBAC, the audit question "who can send commands?" has a simple answer: everyone holding the roles that include that right. With ABAC, the answer depends on combining policies and attributes, so good tooling matters. On the other hand, ABAC copes much better with the shapes real organizations take: many sites, many customers, people who own some resources and only watch others.

In practice, most modern systems mix the two. Roles survive as readable labels, while attributes such as organization, ownership and site decide the exact scope. If you're choosing a model for a growing deployment, the useful question is whether the system lets you narrow access by site or customer without inventing a new role each time.

What is IoT access control?

IoT access control is a phrase with two meanings, so it's worth separating them. In the building-security trade, it means physical access control: badge readers, door controllers and the systems that decide who can enter a room. This article uses the other meaning: controlling who and what can reach connected devices, their data and their controls.

That second kind of access control has more layers than an office application. Each device needs its own identity and keys, so that one stolen key doesn't open the whole fleet. If 200 sensors share one key and a single unit is pulled off a wall and read out, all 200 are exposed; with a key per device, the damage stops at that one unit. The network decides which systems can talk to the devices at all. The platform decides which people can see readings, edit automations or send commands. Integrations and scripts need their own scoped credentials. And increasingly, AI agents query devices and send commands on a person's behalf, which only stays safe when the agent is held to that person's permissions instead of receiving a master key.

Access control is also the main working tool for IoT data privacy. Sensor readings look harmless, but they describe behavior. Occupancy and door data show when an office is empty. A GPS tracker's history shows where a vehicle parks overnight, which often means where its driver lives. The EU's General Data Protection Regulation (GDPR) asks for data protection by default in Article 25, including that personal data isn't made accessible to an indefinite number of people without the individual's intervention. For a connected deployment, that translates directly into who can open which dashboard and which history.

What is a multi tenant IoT platform?

A multi tenant IoT platform serves several separate customers, or tenants, from one installation, while keeping each tenant's devices, data and users apart. The tenant boundary sits outside every role: a facility manager in one tenant should have no way of even discovering that another tenant exists.

Before you rely on any platform's tenant boundary, test it yourself. Create two tenants, give one test account a role in only the first, and confirm that nothing from the second appears anywhere, including search results and API responses.

Three groups depend on this. System integrators run deployments for many clients and need to switch between them without mixing data. Property managers often serve several owners whose buildings must stay separate. Hardware makers sometimes operate a platform on behalf of their own customers. All three spend their working day moving between tenants: one client's devices in the morning, another's after lunch, ideally without a separate login for each and with the right permissions in each place.

What is the best multi tenant IoT platform?

For that kind of work, the best platform is one where the tenant boundary, the permissions of each person and the credentials of each script follow one consistent model. Kilo is the best choice for an integrator or property manager in that position, because of three things you use in it every day.

In Kilo, the unit that separates one customer's deployment from another is the organization. One account can belong to several organizations and switch between them, so you move from one client's deployment to the next without a second login, and what you can do depends on your membership in the organization you're working in.

Inside an organization, Kilo sets access per page instead of through a single role selector. Pages such as Devices, Rules, Connectors, Subscription and Manage Users each get Edit, View or No access for every person, and the decision is attribute-based, taking membership, ownership and those assigned permissions into account. An installer can get Edit on Devices and No access on Subscription, while a client contact gets View on the pages they need and nothing else. The IoT security page lays out the whole permission model, including organizations and the audit trail.

Scripts and integrations get their own API keys in Kilo instead of borrowed logins. A key is bound to one organization, scoped per area, usually with separate Read and Write scopes, grants nothing until you select scopes, and can carry an expiry date. Rotating it deactivates the old value immediately, so the reporting script from the least privilege example could run with Read scopes only, and rotating its key would cut off a leaked copy at once.

Role based access control FAQ

What are the three rules of role based access control?

The original 1992 NIST paper defines three rules. Role assignment: a user can run a transaction only after selecting or being assigned a role. Role authorization: a user's active role must be one they're authorized for. Transaction authorization: a user can run a transaction only if it's authorized for their active role. Later descriptions often call the third rule permission authorization.

What are the main components of role based access control?

The ANSI INCITS 359-2004 standard defines four components: core RBAC, hierarchical RBAC, and static and dynamic separation of duty. Static separation of duty means two conflicting roles can never be assigned to the same person; dynamic means a person may hold both, but can't activate them in the same session.

Is least privilege the same as zero trust?

No, but zero trust depends on it. NIST Special Publication 800-207, published in 2020, defines zero trust as an approach where no request is trusted because of its network location, and every access is authenticated and authorized per session. Least privilege is one of its tenets, applied to each of those sessions.

Does role based access control help with GDPR compliance?

It helps, but the GDPR doesn't name a specific model. Article 32 requires appropriate technical and organizational measures for the security of processing, and limiting who can see personal data is one of the clearest such measures to document.

To see least privilege from the other side, set up a small sandbox on Kilo's free plan. It's the full platform rather than a trial, covers up to five devices, one dashboard and one rule, needs no payment details and never expires. Register a few sensors, or emulated ones that generate their own readings while the hardware is on its way, put them on the dashboard, and invite a colleague who already has their own Kilo account with View on Dashboards and No access on Devices and Rules. Then ask them to sign in and tell you exactly what they can and can't reach. If anything shows up that shouldn't, change that one page's setting and have them check again.