Kuray Karaaslan
@kuray-karaaslan · Joined August 2026
- Topics
- 11
- Replies
- 28
- Points
- 0
Forum Replies Created
No. Groups and policies decide on the action, and IoT pages pass no device attributes to policies, so a member who may view devices sees all devices of the organisation. If the north plant must never see the south plant’s devices, they belong in two organisations. One account can be a member of both, with a different role in each.
Two ways.
If no User should send commands, untick iot_rpc.send.basic for User on the Access Rights tab.
If it’s only the contractors, put them in a group (key contractors, say) and add a Deny access policy: actions iot_rpc.send.basic, iot_rpc.send.privileged and iot_device.attributes.write, condition subject.roles contains contractors. A deny wins over any permit. Policies need the Owner role. Turn on shadow mode first and watch the decision log for a few days before you enforce it.
That’s the oldest session being ended each time a Pi signs in. Give each screen its own account if your plan’s seats allow it. Then the sessions stop fighting, and the audit log shows which screen did what instead of 12 identical actors. If the screens only show a board, look at display links instead: a display link shows a shared board on a screen where nobody signs in.
Immediately. The device using that session is signed out at once, and if it’s the one you’re on, you’re signed out too.
From Members, open the person and use Sign out: they are signed out of the organisation on every device at once. They can sign in again, so if you want to keep them out, suspend them instead. Every sign-in and sign-out is in the audit log, so filtering on auth.login and auth.logout tells you who used the organisation and from where.
For the shared PCs: tell people not to tick remember me there, and to sign out when they leave.
The requirement is checked on every request, not only on the password form: from the moment it’s on, every request has to come from a session that completed a second factor. A session without one gets “This organization requires two-step verification. Sign in again and complete it.”
In an organisation like yours the shortest path is a passkey. A passkey sign-in counts as a completed second factor on its own.
Two different things.
A trusted device skips the second factor for a while, 30 days at most, and still asks for the password. You see those under My Profile > Security, with Revoke and Revoke all.
Remember me changes how long the session itself lives: every session has an absolute lifetime, and ticking remember me makes it longer. Ending sessions works as before, from Active Sessions on your profile, or an admin signing a member out of the organisation.
Every row holds the time, the actor (a member, an API key, the system or a service), the action, its severity, the resource, and the address and browser. Secrets, passwords, tokens and attribute values are never written. The log is hash-chained and you set its retention to what your compliance rules need. Export CSV downloads the rows for the date range of the filter. What is audited lists the actions by area, and Audit log covers reading, exporting and verifying it.
Welcome Daniel. The checklist for a new organisation on the Security page is a good place to begin: a passkey plus a backup passkey for every owner and admin, Require two-step verification for every member once everyone has a second factor, at least two owners or admins, and field staff on the User role. Device profiles on TLS only (port 8883) and allowed networks for fixed sites are on the same list.
Per region. Devices connect to the device host of the organisation’s region. Use the host on the device’s Connection details card rather than typing one from memory.
An organisation has one home region, so all of its data sits in one place. If the warehouse data has to stay in the US and the plant data in the EU, that’s two organisations. Each organisation has its own members and roles, which is often what you want anyway. Each region is also a separate deployment, so ask support how sign-in works across the two before you plan around one login.
Per organisation. Each organisation has one home region and your members sign in to it from wherever they are. Its devices connect to the device host of that region too. Changing the home region later is something only Hermetry can do, through the contact page, so pick it before you connect a fleet. More on Regions and data residency.
Both are on the Residency page of the organisation settings (/admin/settings/residency, owners and admins).
Backups: it shows the class of place where backups are kept. Until that is reported for your node it says not attested, rather than guessing.
Operator access: there is an emergency (“break-glass”) procedure. A grant is time-limited and needs two signatures, every action taken under it is marked in the audit log of the organisation it touches, and the grants of the last 365 days are listed on that same page. The page also lists the region’s sub-processors and its region facts (residency class, legal area, jurisdiction, legal frameworks). The region facts are signed by our control plane, so the page can’t show facts that weren’t issued for your node.