How Omniris decides who can sign in, what each person can see and change, how your files are encrypted, where your data is kept on each edition, and what happens to it when you delete it.
Drone data is often sensitive: the inside of a plant, the roof of a home, a crime scene, a power line. The people who own it need to know exactly who can open it, and to be able to prove it. Omniris is built so that access is never assumed. Every request to see, download or change a file is checked against your permissions at the moment it is made, and the files you choose to protect are encrypted so that the key to open them is released only to the people on their access list, and to Omniris itself for the work you ask of it.
Use Google, Apple, Microsoft or Facebook, a passkey on your phone or laptop, or a one-time code sent by email. On-premises sites can also use email and password.
What you can see depends on where a folder lives: your vault, your organization's vault, a folder shared with you, or a job you are working. Move a folder and its access moves with it.
Viewers, read-only shares and delivered results can be looked at but never changed. Delivered results can't be downloaded until they are accepted.
Encrypt a file or a whole folder with OpenTDF, an open standard for files that carry their own access rules. Every opening is checked for that person, and opening a protected picture, video or download is recorded.
Hosted sites use HTTPS only. Files travel directly between your device and storage over short-lived signed links.
Omniris cloud on Microsoft Azure or Google Cloud, the data center edition, or on your own servers, where your files and your encryption keys stay on site.
Uploads, views, downloads, shares, encryption and deletion are all recorded in a tamper-evident custody record you can search and export.
Omniris offers several ways to sign in. Most of them involve no password at all, so there is no password to steal, reuse or forget.
| Method | How it works | Where |
|---|---|---|
| Google, Apple, Microsoft, Facebook | Sign in with an account you already have. Omniris checks the signed answer that comes back from the sign-in service and never sees your password for that account. | Every edition, while the site can reach the internet |
| Passkey | A passkey is a sign-in key kept by your phone, laptop or password manager and unlocked with your fingerprint, face or device PIN. Omniris asks for that unlock every time. | Every edition, over HTTPS |
| Emailed code | Omniris emails you a 6-digit code. It works once, for 10 minutes. Five wrong tries cancel it. | Every edition |
| Email and password | A password of at least 8 characters, stored only as a one-way scrambled form (a hash) that can't be turned back into the password. New accounts confirm their email address first. | On-premises only |
| This device | The desktop app, or a browser that has signed in before, keeps a key of its own and can sign you in again without the internet. | On-premises only |
A passkey can also create a new account: you confirm your email address with a code, then your device makes the passkey. The emailed code is the way back in if you lose every passkey. Codes are sent only to accounts that were created with a code or a passkey, never to an account that signs in with Google, Apple, Microsoft or Facebook.
On-premises sites choose which of these methods to offer, and the change applies within a minute. At least one method that a brand-new person can use must stay switched on.
Every account except a viewer's has a vault: its own private storage for files and folders. People who work together can also belong to an organization, which has a shared vault of its own. Each member of an organization is a manager, a pilot or a viewer, and one manager is its owner.
| Role | What they can see | What they can do |
|---|---|---|
| Organization owner | Everything a manager sees | Everything a manager does. The owner's plan sets the organization's storage, and only the owner can hand ownership to another manager. |
| Organization manager | The whole organization vault | Add, change and delete files there; invite and remove members; approve the organization's pilots; choose which folders each viewer sees; manage the organization's recycle bin, API tokens and webhooks; publish public links to any organization folder. If the organization is deactivated, its vault becomes read-only. |
| Organization pilot | The organization vault, read-only | Upload results into the folder of a job they are working on. A manager approves each pilot before they can take jobs. |
| Organization viewer | Only the organization folders a manager has granted | Look and download. A viewer has no vault of its own and can't upload, rename, move or delete anything. |
| Client | Their own vault, and results delivered to them | Everything in their own vault. Delivered results arrive as a read-only copy, and can't be downloaded until the client accepts them. |
| Pilot | Their own vault, and the folder of each job they are working on | Everything in their own vault. In a client's job folder, add and change files while the job is assigned, in progress or awaiting acceptance, and not after. |
On-premises sites show the client role as Manager; what it can do is the same.
These rules are applied on the server, to every request, from the web app, the desktop app, the phone app and the API alike. Hiding a button is never the only thing standing between a person and a file. Removing someone from an organization, revoking their share or deactivating their account takes effect on their next request.
Access in Omniris belongs to folders. A file is reachable by whoever can reach the folder it is in, and a folder is reachable through one of these routes, checked in this order:
Everything in it is yours to read and change, except delivered results, which stay read-only.
As your role allows: managers read and write, pilots read, viewers read only the folders granted to them.
As the share allows: read-only, full access, or a frozen snapshot.
A pilot can work in the job's folder while the job is active.
If none of these applies, the answer is no.
Access follows the folder, not its name. When a folder is moved, its access moves with it. A folder moved out of your organization's vault stops being reachable through the organization, and one moved in becomes reachable by its members. Creating a folder somewhere does not give you lasting rights over it: if you leave an organization, the folders you made in its vault stay with the organization.
You can share any folder in your vault with a share code: four groups of four letters and digits that the other person redeems in their own account. You choose what the code allows:
| Share | What the recipient gets |
|---|---|
| Read only | View and download. Nothing can be added, changed or deleted. |
| Full access | View, download, upload, rename, move, copy and delete. |
| Snapshot | A frozen, read-only copy of the folder in their own vault. It points at the same stored files, so it costs neither of you extra storage, and it can never be edited. |
| Transfer | A one-time move of the folder's files into the recipient's vault. Files under a legal hold or retention policy stay with the sender, and both sides are told before it happens. |
A public link opens a folder in any web browser, with no account. You choose whether it allows viewing only or downloading too, and you can add a password and an expiry date; a link made when you send a job's results to a client can also limit the number of views. A link's password allows 10 guesses from one network address every 15 minutes. Revoking the link cuts access at once. Only folders in your own vault can be published, except that organization managers may publish any folder of their organization. Organization pilots and viewers can't publish organization folders. The companion paper on sharing, delivery and integrations covers links in full.
There are two layers. The first, described here, covers everything you keep in Omniris. The second, protected files, adds encryption that travels with the file itself, for the files you choose.
For files that need more than permissions alone, Omniris can protect them. A protected file is rewritten as an encrypted OpenTDF file. OpenTDF is an open standard for encrypted files that carry their own access rules: the file says who may open it, and a separate key service holds the keys and hands one out only to a person on that list.
Each protected file has an access list. People join it in these ways, and each change re-encrypts the affected files for the new list:
The Omniris service itself is always on the list as well. That is what lets it re-encrypt a file when its list changes, and serve a protected file on a public link you choose to publish (below).
The same folder rules as for any file: your vault, your organization, a share or a job. If they say no, nothing more happens.
Omniris asks the key service for the file's key using your own sign-in, not a master key. The key service decides from the file's access list whether you may have it. Without a valid sign-in, the request is refused.
When you look at a protected picture, play a protected video or download a protected file, the decryption is written to the file's custody record before any of the contents leave. Watching a protected video counts as one opening, however often you skip back and forth within 15 minutes; looking at a protected picture is counted the same way.
Downloading a protected file gives you the decrypted original, through the same two checks. Removing protection from a file also needs both: your permission, and the key service's yes for you.
| When | What happens |
|---|---|
| Processing (maps, 3D models, AI detection, LiDAR) | The inputs are decrypted with your sign-in into a temporary working copy for the job, which is deleted when the job ends. Results that land in a protected folder are encrypted as they arrive. |
| Viewing a protected map layer, point cloud, panorama or 3D model | For a map layer, point cloud or panorama, a decrypted working copy is made for you alone, because those viewers read the file in pieces. Nobody else can read it, and it is removed after 24 hours. A protected 3D model is decrypted piece by piece with your sign-in as the viewer asks for each part, and no decrypted copy is kept in storage. Opening one of these in a viewer is written to the file's custody record as a decryption before any of it is shown, once per viewing (one per 15 minutes), never once per piece; if the record cannot be written, it does not open. For a 3D model the record is on the model's main file. |
| Replacing a protected file | Uploading a new version, or re-running the processing that made it, encrypts the new version again for the same people. If that list was never recorded, it is encrypted for the vault's owner only, and the owner is told why. |
| Share codes | Redeeming a share adds the recipient to the protected files' list. A snapshot points at the same encrypted files, so they stay protected. |
| Public links | Publishing a link is your decision to show that folder to anyone with the link. Protected files in it are marked Encrypted and are opened by Omniris for the viewer: a view-only link shows photos as reduced preview images and plays videos, and a download link gives the decrypted files (a protected map is shown on the page as a preview image of up to 4,096 pixels, and its Download button gives the file itself). A protected 3D model opens on a public link too: Omniris decrypts it piece by piece as the viewer asks for each part, as it does for you, and keeps no decrypted copy. (A model packed into a single .3dmodel file cannot be opened in the viewer while it is protected, signed in or not.) Pictures of protected evidence on findings are never shown on shared links. |
| Exports (map, CAD and schedule exports) | Protected sources are decrypted with your sign-in into a working copy that is kept for no more than an hour. An export saved into a protected folder is encrypted. |
| Sending to Procore | Protected files are skipped and listed as "protected, not sent". You can release one file or one folder on purpose, after confirming. A decrypted copy is then sent, decrypted with your own sign-in, and each release is recorded as a decrypted copy released to Procore. Protected pictures attached to findings are not sent with observations. |
| Publishing to ArcGIS | Protected files are never published. If everything selected is protected, nothing is sent and you are told which files. |
| Legal holds | The locked copy of a held file is the encrypted file. Its key is kept with the hold, itself encrypted under a separate recovery key, so held evidence can still be opened later. |
The companion paper Evidence you can prove explains how a protected file's custody record proves that the encrypted copy and the original are the same evidence.
Who holds the keys decides who can, in the end, read the data. Where Omniris runs on your own hardware, the keys are made on your hardware and stay there.
| Key | Omniris cloud | On premises |
|---|---|---|
| Protected-file keys (the key service) | Run by Omniris inside its private cloud network. The key service can't be reached from the internet, only from inside that network. | Installed on the site's own server when the site turns file protection on. Its keys are generated there, never leave the site and are never replaced, because new keys would make every protected file unreadable. |
| The custody record's signing key | Azure Key Vault or Google Cloud KMS; the key never leaves it | The server's TPM security chip, or a protected key file |
| The recovery key for held evidence | Held by the cloud provider's key service | The server's TPM security chip, or a key file generated on the site. For a key file, the site is reminded to copy it to offline storage until someone confirms it has. |
| The key that signs sign-in passes | Omniris's own | Generated for each site, so a pass made on one site is worthless on another |
| API token, webhook and Procore connection secrets | Omniris's own, held apart from the database | Generated on each site and never copied from anywhere else |
Your own provider accounts. An on-premises site needs a few outside services: maps, address search, weather, email and Orion, the AI assistant. Depending on its plan, the site either lets Omniris make those calls on its behalf, so that no Omniris account key ever sits on the site, or uses its own accounts with those providers. Those account keys are entered on the site and stored there encrypted. On premises, you also register your own Procore and Autodesk applications for the integrations, rather than using Omniris's.
The data center edition runs on Omniris's own servers, with its key service, signing key and storage on that hardware, and uses Omniris's own provider accounts.
Omniris comes in four forms. The software is the same; what differs is whose hardware it runs on.
| Edition | Your files and database | Protected-file keys |
|---|---|---|
| Omniris cloud (Microsoft Azure) | Microsoft Azure, West US 3 region, in the United States | Omniris's key service, inside its private Azure network |
| Omniris cloud (Google Cloud) | Google Cloud, us-central1 region, in the United States | Omniris's key service, inside its private Google Cloud network |
| Data center edition | Omniris's own servers | A key service on those servers |
| On premises | Your own servers, on your premises | A key service on your own server |
Each Omniris cloud keeps its files and its database together in that one region.
An on-premises site is a normal connected installation. Your files, your database, the processing of your maps, 3D models and AI detections, the key service for protected files and the custody record all stay on your servers. The main things it reaches out to the internet for are these, plus any outside system you connect it to yourself, such as Procore:
| Reaches out for | What is sent |
|---|---|
| Signing in with Google, Apple, Microsoft or Facebook | The sign-in itself, between your browser and the sign-in service. Passkeys and passwords don't need it. |
| Map backgrounds, address search, weather and email | The map area on screen, the address or place searched for, a location for the weather, an outgoing email. Usually made through Omniris on the site's behalf (see your own keys). Omniris counts these calls for billing and never logs the address searched for or an email's recipient. |
| Orion, the AI assistant (see the Orion paper) | The question and the information Orion needs to answer it. Omniris counts the call for billing without logging the question or the answer. |
| The site licence | A renewal request, identified by the site's key |
| Hybrid processing | Only when someone chooses to run a particular job in the Omniris cloud: that job's inputs, and its results back |
| Independent timestamps for the custody record | A fingerprint of the record, never its contents (see Evidence you can prove) |
If the connection drops, the site keeps working. People already signed in stay signed in, a desktop app or browser that has signed in before can sign in again, and features that need an outside service say plainly that they can't reach it.
Every file has a custody record: its complete history, sealed so that any later change to the history shows. It records uploads, views, downloads, shares and each time a share is used, moves and renames, encryption and decryption, changes to who may open a protected file, transfers between accounts, processing results, and deletion and restoration. Each entry says who acted, when and from where.
How the record is sealed, timestamped by independent authorities, checked every day, and turned into certificates is the subject of the companion paper Evidence you can prove.
Deleting a file, a folder or a finding moves it to your recycle bin, shown as the same folder tree it came from. From there you can put it back where it was, or delete it forever. Anything left in the bin is erased from storage for good by a daily clean-up once its time is up: 30 days by default. An organization has a recycle bin of its own for its vault, which its managers look after.
A legal hold freezes evidence so that it can't be changed or deleted. A retention policy keeps data for a set period, then releases or deletes it. Anything they protect is refused before you confirm a deletion, with the reason. They are described in full in Evidence you can prove.
Deactivating an account is different: it stops the person signing in at once, and deletes nothing.
Outside systems, such as a work-order system, a mapping (GIS) system or a script, can read and update your findings through the Omniris API, and be told about changes as they happen through webhooks. The companion paper Findings you can act on describes what they can do; this is how they are kept safe.
Security depends on knowing exactly where the edges are. These are Omniris's.