Most work apps now run in the browser, and most of them can be opened from anywhere. That is convenient, and it also means a username and password, or a stolen session, can be used from any computer in the world. Tying access to a known device narrows that down. The question becomes not only “is this the right person?” but “is this the right person, on a device we enrolled?”
This guide covers what a known device adds, where it stops, and how to set up per-person, per-app access without opening new gaps when people join and leave.
Network access is not app access
For years, being on the office network or the VPN was treated as a sign that someone belonged. That assumption does not hold when the apps are in the cloud and the people are at home, at a client’s office or on the road. Reaching a network says nothing about which work apps a person should open, and a stolen password works just as well from outside the network as from inside it.
Modern access design starts from the person and the app instead. Who is this? Which apps does their job need? And which device are they using right now?
What a known device adds
A known device is one your organisation has enrolled and tied to a named person. When sign-in is bound to that device, three things improve.
A stolen password is not enough. With device-bound sign-in there may be no password at all, and the key that signs the person in was created on their enrolled hardware. An attacker working from their own computer has nothing that works.
Every sign-in has a name and a machine attached. When an auditor or an incident responder asks who opened the payments app last Tuesday, the answer is a person and a device, not just an account name.
Removing a device is a real control. If a laptop or phone is lost, removing that device from the console stops it being used to sign in, without waiting for a password change to reach every app.
Start with the person and the app
Device binding works best on top of a simple access model: each person gets the apps their job needs, granted per person and per app, rather than everything by default. In CyberCyko, IT decides which apps each person can open, access is tied to the device the person enrolled, and the employee confirms sign-in on their enrolled phone with a fingerprint or face.
That gives the administrator one place to review and change access. It also makes least privilege practical. When granting one more app takes a click, there is less temptation to give everyone everything “just in case”.
For apps that hold sensitive data, such as a payments dashboard or a customer database, ask for a second approval before they open. CyberCyko calls this step-up approval, and it comes with a remember-this-device window so people are not asked every few minutes.
What a known device does not do
Binding access to a device is not the same as checking the device’s health before every sign-in. Some products block an app when a laptop’s disk encryption is off or its updates are late. CyberCyko does not offer a rules engine of that kind today. It reports each enrolled Windows laptop’s settings and checks in the console, and access is decided per person, per app and per enrolled device.
A known device also does nothing for apps that cannot use standard single sign-on. Those keep their own sign-in. List them, decide who owns each one, and include them in your joiner and leaver steps so nothing is forgotten.
Removal has a precise meaning
Removing someone’s access in CyberCyko blocks future sign-in through CyberCyko, within seconds for devices that are online. It does not delete the person’s account or its data inside the external application.
That distinction matters when someone leaves. IT may still need to hand over files, close a mailbox or follow the external application’s own account and data-retention steps. A useful leaver checklist has two parts: cut sign-in in one place first, then tidy each app’s accounts on a timetable you choose.
Every grant and removal is recorded in a tamper-evident admin log, so the answer to “when did their access end, and who ended it?” is on record, and any later edit to that record shows up when the log is checked.
Review setup before rollout
Ready-made setup exists for Microsoft 365, Google Workspace, Slack, GitHub, GitLab, Mattermost and Redmine. Anything else that supports standard single sign-on is added through a guided wizard with a test-connection button.
Microsoft 365 domain sign-in is different. It hands sign-in for a whole domain over to the identity provider, so it uses a guided setup with help from the CyberCyko team. Review the domain, the affected users and the rollout plan before making the change, and start with a small group.
The single sign-on page explains the current flow and its limits.
A short rollout checklist
1. List every work app, and mark which ones support standard single sign-on.
2. Decide who needs each app, and grant access per person rather than to everyone.
3. Mark the sensitive apps that should ask for a second approval.
4. Enrol a few laptops and phones first, check that sign-in and removal behave as you expect, then widen the rollout.
5. Write down the leaver steps for each external app, so removal in one place is always followed by the account clean-up that app needs.
See how it works in CyberCyko Workforce
See work-app access Related