Admit private devices

A person also works from their own laptop, outside the domain and without device management. There they should reach only what they need on the road, with a code from their authenticator app, and it should be possible to withdraw that access on its own at any time, without touching their company PC.

The service doesn't recognize a private device as such (see Zero Trust and private devices). It does distinguish the sign-in method: the company PC signs in with the Windows account, the private device with its own personal key. You restrict this key to what's needed, and a sign-in rule requires the second factor for personal keys outside the corporate network.

1. Set up the person's second factor if not done yet: enroll-totp of the administration interface with "delivery": "link" or "mail", or the person sets it up at their first sign-in.

2. Issue the key with issue-key:

   { "person": "Erika Muster", "label": "Private laptop", "expiresAt": "2027-03-31T00:00:00Z",
     "readOnly": true, "databases": [ "fachdaten" ], "delivery": "link" }

   Rights come only from the person's rules; the key restricts them and never extends them.

3. Create the sign-in rule with save-sign-in-rule if it doesn't exist yet:

   { "scope": "Data", "method": "PersonalKey", "effect": "RequireTotp",
     "label": "Keys from outside only with a code", "exceptFrom": [ "10.0.0.0/8" ] }

   Enter your corporate networks under exceptFrom. Check first with explain-sign-in; see check a rule before enforcing it.

4. Enter it on the laptop: in the ODBC driver (Access) as a key; before the first query the driver asks for the code in a dialog and keeps the session for the process. Excel and Power BI can't ask for a code: for them, issue a separate read-only key exempt from the code; see separate reports from refresh.
5. Check: explain-sign-in for the person with an origin from the internet shows code for the new key. After the first real sign-in, the event appears in SignInEvents with Method = personalKey and Outcome = totpSuccess; in PersonalKeys the key shows „last used“ with its origin.

Result: The laptop reaches only the alias fachdaten, read-only, only with a code from outside, until the key expires. The person's company PC isn't affected.

• What stays on the laptop isn't controlled by the service. Retrieved data lives there in Excel, Power BI, or Access. Where that's not acceptable, release only views that leave out sensitive columns (see restrict agents to their customers).
• One key per device. If the laptop is lost, you revoke only this key; see respond to a lost device.
• Networks on the key (from) bind a key to known networks, for example a home network with a fixed address. That rarely suits laptops on the road.
• Self-service: People can issue their own keys; these always expire and can set neither networks nor the exemption from the code (see sign-in).
• The click paths in the administration app are described in the „Administrator guide for WKL Database Gateway Manager“.

• Zero Trust and private devices
• Tier access by location
• HTTP: sign-in (reference)