A More Flexible Access Control Model for Telematics Operations

Whether you run your fleet operations directly, provide telematics services to other businesses, or work as a systems integrator configuring hardware and software for customers, access control matters to you. Navixy already lets account owners define custom roles and restrict which devices, geofences, and data a given user can see.

We are now building a unified Identity and Access Management (IAM) layer: a central mechanism that determines who a user is, whether they are an employee, partner, or integrator, and which products, objects, and actions they can access. This layer will extend access control across workspaces, products, and external partners, providing the foundation for more precise roles and permissions.

Here's what will change, why it will matter for end-customer companies, telematics solution builders, and integrators alike, and how it will look in practice.

Current user roles and access control in Navixy

Navixy already supports Users and roles: account owners can create custom roles with specific access rights, and restrict a given user to specific GPS devices, geofences, and places. That's a solid foundation — but it has some natural limits, which is where the new architecture will pick up:

How the new access model will benefit fleets, telematics solution builders, and systems integrators

Benefits for fleet operators

Fleet operators will be able to control exactly what each employee or external specialist can see and do across Navixy products. Instead of managing access device by device, they will be able to assign permissions based on a person's responsibilities and limit access to only the data and tools they need.

This will also make onboarding easier. New employees and temporary specialists will receive the right level of access from the start, and an expiration date can be set for any role assignment so that access is revoked automatically when it is no longer needed. Other outdated permissions will be easy to identify and remove.

Benefits for telematics solution builders

Telematics solution builders will no longer need to rely on a single master user to handle every access request and account change. Full administrative permissions will be delegable to other trusted users, allowing support teams to distribute responsibility and respond to a high volume of customer requests more efficiently.

They will have clearer control over which products, assets, and data each team member can access. This will reduce bottlenecks, speed up onboarding, and help support teams resolve customer issues faster.

Benefits for systems integrators

Systems integrators will be able to give their specialists access only to the products and assets required for a specific project. Customers will have greater confidence that external teams cannot view or change anything outside the agreed scope of work.

As access requests will be more specific, customers will also be able to approve them more quickly. This will reduce delays at the start of a project and make it easier to remove access once the work is complete.

Real-world access control use cases

Case 1. A systems integrator and a construction company

A construction company brings in a systems integrator to configure IoT Logic across its active sites. The goal is to automate equipment monitoring so that events such as unauthorized movement, excessive idling, low fuel levels, or after-hours use trigger an immediate alert instead of being discovered during a manual inspection. The company already has internal roles in place, including site managers, fleet managers, and safety officers, each with their own responsibilities.

Instead of giving the integrator full access to the customer's account, the integrator's specialist, Sam Brown, will receive access only to IoT Logic and the 15 trackers installed on the excavators, loaders, and generators he is responsible for configuring. Other products, construction sites, assets, and customer data will remain outside his scope of access.

This setup will allow the construction company to retain full control over its data while giving Sam exactly the permissions needed to complete the configuration. Limiting access to a specific product and group of assets will reduce unnecessary data exposure and support privacy-by-design practices.

Case 2. A telematics solution builder supporting many customers at once

A telematics solution builder supports dozens of customer accounts. Today, responding to a single customer's support ticket usually means adding a support specialist as a regular user on that account — access that often ends up being permanent, rather than scoped to the incident.

Under the new model, a support specialist's access will be granted to one specific customer workspace, for a limited time, and will be fully visible to the customer — who will be able to see exactly who accessed their data, when, and why.

This time-limited, workspace-specific access will help telematics solution builders support more customers without accumulating outdated or overly broad permissions. It will also reduce the administrative burden on customers, as an expiration date can be set in advance so that access is revoked automatically at the end of the specified period.

Case 3. A logistics company with multiple depots

A transportation company operates several depots, each with its own manager. Today, restricting a user to a device or two works, but there's no simple way to say "this manager sees Depot 1" and "this regional lead sees Depot 1 and Depot 2" as the fleet grows into the hundreds.

With access scoped by tags or object groups, the company will be able to grant a depot manager access to just their depot, and a regional lead access to several at once — without maintaining per-device lists by hand.

This group-based approach will make access easier to manage as the company expands. Each employee will see only the depots and assets relevant to their role, without the need to update long device lists manually.

Case 4. A developer building a custom telematics solution

A software developer is building a custom fleet application for a vehicle leasing company using Navixy as the underlying telematics platform. The application brings together vehicle locations, driver data, maintenance information, and operational workflows in an interface designed specifically for the customer's teams.

With the new IAM layer, the developer will be able to define access directly around the application's business logic. Fleet managers may receive access to the entire fleet, regional managers only to vehicles in their area, and external service providers only to the assets and functions required for a specific task. These permissions can apply across Navixy products, workspaces, and system objects, including vehicles, drivers, devices, and custom objects.

This will allow the developer to build access control into the solution from the start instead of creating a separate permissions system for every customer. The customer will gain a more secure and scalable product in which every user sees only the data and functionality relevant to their role.

What's next for role-based access control in Navixy

We are actively developing this new access model, building on the Users and roles functionality already available in Navixy. The goal is to make access management more flexible, consistent, and secure across products, customer workspaces, and external teams.

As development progresses, we will share more details about how the new model will work in practice. To learn more about Navixy and its access management capabilities, get in touch with our team.