Regaining control of shared devices

Network-enabled access devices have a failure mode that traditional, isolated controllers do not: anyone who can reach the device can integrate it. That is usually a feature — it is what makes a gate easy to automate and share. But it also means a careless or well-meaning user can quietly hand out access at scale, and the person actually responsible for the device can lose control of it.

This page describes that scenario and how OpenApp’s device-level policies let the verified hardware owner take control back.

Vendor example

This guide uses PalGate as a concrete example because it is a network-enabled gate controller with a real administrator concept. The mechanism is generic and applies to any integration that exposes a verifiable hardware identity and a hardware-admin notion. OpenApp is not affiliated with PalGate.

The scenario: a shared gated community gate

Imagine a gated community with a single main vehicle gate on the access road. A security officer installs a PalGate controller on the gate and administers it.

Then things drift:

1. Several residents discover that OpenApp integrates PalGate. Each creates their own OpenApp integration pointing at the same physical gate.
2. Each of them starts issuing invitations and open privileges to friends, contractors, and visitors.
3. Because every one of those integrations is internally valid — each user is operating within their own organization’s roles — nothing looks wrong from any single vantage point.
4. Collectively, the security officer has lost control: people are opening the gate whom the officer never authorized, through integrations the officer cannot see or manage.

This is not a bug in any one organization’s setup. It is a structural gap: ordinary org-level and integration-level controls only constrain within an organization, and the gate is being used by many organizations at once.

The mitigation: device-level policies

A device policy is the highest tier of OpenApp policy. It is attached to the real-world physical device, not to any one organization’s copy of it, and it binds every organization and integration that points at that same hardware.

So the security officer can, for example:

• Set a curfew so invitations cannot open the gate at night — applied to every org using the gate, not just their own.
• Block or require approval for users sharing gate access.
• Cap invitation duration, restrict entry kinds, and apply any other catalog policy.

Crucially, device policies are restrict-only: the owner can clamp the gate down for everyone, but cannot use this tier to widen anyone else’s access. The owner regains control without gaining the ability to interfere with how other organizations otherwise operate.

If this is your gate — close the hatch now

If you administer the gate in PalGate but residents have already connected it to OpenApp, you can regain control without waiting for them:

1. Create an OpenApp account and sign in to the dashboard. Link with the gate administrator phone in PalGate — a non-admin account cannot set device policies.
2. Add a PalGate Cloud integration and create a device for your gate (enable Linked Device in the PalGate app first). The wizard verifies that you are a gate administrator.
3. On the integration’s Policies tab, set Device-tier user sharing control for that gate — for example block non-admins from sharing access, or require admin approval. Saving the first device policy claims stewardship; the limit then binds every organization using this gate.

You do not need residents’ cooperation. As soon as your policy is saved, it applies to all existing integrations pointing at the same physical gate.

Who is allowed to set device policies

Device policies can only be set by the verified hardware owner — what OpenApp calls the device steward.

• The steward must be a verified administrator of the actual device. For PalGate, that means the integration’s linked account is a real gate administrator — exactly the same check behind Linked Device and the Secondary device not authorized state. A non-admin (“redacted”) linked account can never become a steward.
• There is exactly one steward per physical device. PalGate allows several administrators per gate, so to avoid conflicting policies, OpenApp grants stewardship to the first verified admin who sets a device policy, and only one at a time.
• If the steward’s device record (or integration) is later removed, stewardship is released: the device policies remain in effect, but the steward slot is empty until the next verified admin claims it.

Why stewardship needs a real admin

The steward tier only exists for devices that have a genuine, verifiable owner — like a PalGate gate administrator. For devices with no administrator concept (a bare relay where anyone with the credentials has full control), OpenApp deliberately does not offer stewardship: it would be wrong to let whoever connected first lock out everyone else who equally controls the device. Those devices are still recognized as “the same physical device” across organizations for visibility, but no one can impose cross-org limits on them.

You cannot fake ownership

Because device policies bind other organizations, the device identity must be trustworthy. OpenApp does not let a user assert it:

• The hardware identity is auto-detected from the provider, never typed in by a user. It is read-only to everyone, including admins — there is no field to set it.
• Becoming a steward requires passing a live admin check against the real device. Forging the identity of someone else’s gate is useless: without genuinely administering that gate, the check fails and no stewardship is granted.
• Ownership is continuously re-verified. If a device can no longer be confirmed, or admin rights are lost, the steward’s authority is suspended until it is re-verified — OpenApp fails safe rather than trusting a stale claim.
• You cannot dodge a device policy by renaming your device, either: a record pointing at a gate you do not actually control cannot open that gate upstream in the first place.

What other organizations see

When a device is governed by a hardware-owner policy, other organizations using that device are told that it is governed by the device owner, so that any denial is explainable — without exposing the steward organization’s private details. They can keep using the device within the owner’s limits, but they cannot edit or remove the device-level policy.

Related

• Policies — the full three-tier model
• PalGate permissions and Linked Device — how gate-admin status is determined
• Choosing access control architecture — connectivity and ownership trade-offs