Security you can defend to IT

Tenant isolation

Security in a maintenance platform is not just about who can log in — it is about whether the system prevents bad data and bad processes from being recorded in the first place. AssetAI's controls are designed around that principle, at every stage from the shop floor to the admin dashboard.

Where the Controls Actually Live

Most CMMS security claims stop at login screens. AssetAI enforces two of its most important rules in the application code itself, not just in the UI:

• A breakdown or corrective-maintenance work order cannot be completed or closed without a recorded failure cause and failure remedy — checked in two separate code paths, so it can't be bypassed by skipping a form field.
• Emergency-severity breakdowns raise a work order immediately, bypassing approval, while every other severity is routed through an approval step before a work order is created.
• The external-repair loop moves through a fixed sequence — Requested → Visited → Quoted → Quote Approved → In Service → Completed → Billed → Bill Passed → Closed/Cancelled — with an automatic time trail recorded at each transition.

This matters more than it sounds. On a busy line, an operator under pressure will close a ticket without writing down what actually failed unless the system stops them. Building that check into the code, rather than trusting a form or a supervisor's memory, is what keeps failure-cause data usable for OEE analysis and root-cause reviews months later rather than a field full of "fixed" and "OK now."

What Shop-Floor Access Looks Like in Practice

India's manufacturing floors run on shared terminals, gloved hands, and workers who don't want to manage yet another app login — AssetAI is built around that reality, not against it. Operators log breakdowns and meter readings by scanning a QR code on the asset, typing their name, and entering a company-wide scan PIN. There's no app install and no per-user credential to forget at the point of failure.

Be clear-eyed about the trade-off: this is a shared-secret model, not per-operator authentication. The PIN is common across the company and the operator name is free text, unverified against any directory. It is designed for speed and adoption on the floor, not for forensic attribution of who logged what. If your plant needs individual operator accountability at the point of scan, that's a conversation worth having on a demo before you roll this out.

Above the shop floor, access is scoped in two tiers:

• Super admins see a platform-wide dashboard — total companies, active companies, total users, most recent companies onboarded.
• Tenant users see only their own company's dashboard, with all assets, breakdowns, work orders, PM schedules, spares, AMC records, and analytics scoped to that company.

This is a two-tier model, not granular per-module role-based access — if your organization needs finer-grained permissions per department or per user role, ask about it directly rather than assuming it exists.

Where to Verify Before You Commit

Every plant's compliance requirements differ, and this page describes mechanisms, not certifications — check our standards page for how we map to frameworks like ISO, and read up on what a CMMS actually is if you're evaluating this as your first system. For broader context on how Indian manufacturing is scaling digitisation, IBEF's industry data is a useful starting point. Compare this against other features or use cases before deciding — and if a specific security question isn't answered here, raise it on the call.

AssetAI's security model is built to satisfy an IT audit as readily as a plant manager's common sense — it separates who can see what, and it is honest about where responsibility still sits with your own team, not just the platform.

Two Admin Tiers, One Accountability Model

Every company on AssetAI sees only its own data — assets, breakdowns, work orders, PM schedules, spares, AMC records, analytics — scoped consistently across the platform. On top of that scoping sits a simple two-tier access model:

• Super admins get a platform-wide dashboard: total companies, active companies, total users, and the most recently onboarded companies. This tier is for AssetAI's own operations team, not for plant staff.
• Tenant users see only their own company's dashboard — no visibility into other companies, no cross-tenant reporting, no way to query outside their scope.

This is deliberately a coarse split rather than a granular, per-module permission matrix. If your governance process requires role-based access down to individual screens or actions, treat that as a gap to plan around, not an assumption to make. It's worth reviewing this against your own ISO or internal IT policy requirements before rollout — our standards page has more detail on where AssetAI aligns with common compliance frameworks and where it doesn't yet.

Where the Model Stops Short — Read This Before You Deploy

A credible security page tells you what isn't covered, not just what is. Three limits matter for procurement and risk review:

• There is no granular RBAC below the super-admin/tenant-user split — every user inside a company effectively shares the same visibility into that company's data.
• The shop-floor scan flow is not individually authenticated. The scan PIN is a shared, company-wide secret, and the operator's typed name is free text, unverified against any login. It's designed for speed at the point of failure, not for identity assurance.
• There is no documented immutable or append-only audit log. Approval stamps and status-transition timestamps are recorded, but if your compliance program requires tamper-evident, write-once logging, confirm that separately with your implementation team.

None of this is unusual for a plant-floor CMMS, but it should factor into how you classify AssetAI within your own risk model — particularly if you operate under stricter data-governance rules than typical for manufacturing environments.

Fitting This Into a Broader Compliance Program

Security controls on a maintenance platform rarely stand alone — they usually need to sit alongside quality and reliability programs your plant already runs, such as TPM or an OEE-driven improvement cycle. AssetAI's approval gates and mandatory failure-cause logging exist partly to make sure the data feeding those programs is trustworthy — a breakdown record with no cause and no remedy is worse than no record at all.

If you're evaluating AssetAI against an existing CMMS or building a first-time maintenance system, it's worth reading through our use cases to see how these controls behave across different plant scenarios, and comparing that against your pricing tier requirements — access-tier limits sometimes differ by plan. For anything not answered here, the fastest path is a direct conversation: book a demo and walk through your specific compliance checklist with our team before you commit.