Security Guide · For Managers
Sentinel guards the network: it decides which devices may reach your systems at all. Sign-in guards the application: it confirms which person is using them. Each works without the other, so an attacker has to beat both, separately.
Should this device be talking to us at all?
Answered at the edge of your systems, before the application sees a single request.
Is this the right person, and what may they do?
Answered by the login and your organisation’s identity provider, once a request has been let through.
A strong password doesn’t help if the login page is open to the whole internet. A private network doesn’t help if anyone on it can log in. You need both answers.
Every time someone opens an entityOS system, their request passes through four checks, in this order. The first two belong to Sentinel. The last two belong to sign-in.
Fail any one check and the request stops there. Nothing after it runs. An attacker has to pass all four, and the four rely on different things.
Decides which networks and devices can reach your systems. People on the right devices barely notice it. Everyone else is turned away before they see anything.
A guest list of internet addresses: your office, your company VPN, an admin workstation. Requests from any other address are turned away at the edge, so the login page never even loads for them.
In everyday terms: a gatehouse that only lifts the boom for registered number plates.
Each approved laptop or phone holds a digital certificate issued by your organisation. The connection itself proves the device has it. No certificate, no connection, even from an approved address. Lose a device, revoke its certificate, and it is out.
In everyday terms: a security pass built into the device and checked electronically at the gate.
Confirms which person is at the keyboard and what they are allowed to do. This is the part most staff already know, and most organisations already have.
One company account opens every system. When someone leaves, IT disables that one account and their access ends everywhere at once.
In everyday terms: one staff ID card instead of a separate key for every room.
A second proof after the password, such as an approval in an app or a one-time code. A stolen password on its own is no longer enough.
In everyday terms: a PIN on top of the bank card.
A sign-in stored on the person’s own device and unlocked with a fingerprint, face or PIN. It only works on the genuine website, so a fake login page can’t capture it.
In everyday terms: a key cut to fit only your real front door.
The two layers don’t share anything an attacker could steal once and use twice. That separation is what makes them add up rather than overlap.
Because neither layer relies on the other, a weakness in one doesn’t open the other. A stolen password doesn’t come with a device certificate. A stolen laptop doesn’t come with its owner’s fingerprint.
Real incidents usually start with one thing going wrong. Choose one to follow an attacker through the four checks.
Most organisations already have sign-in. Sentinel puts a second, independent layer in front of it, and each one covers what the other cannot see.
The login page is open to the whole internet. Anyone, anywhere, can try it as often as they like.
Only approved networks and devices can connect, but whoever is holding one of them gets straight in.
An attacker needs an approved network, an approved device, the right account and the person’s own passkey, all at the same time. Each comes from a different place.
Two layers don’t make a system unbreakable. They mean a single mistake, a single stolen password or a single software flaw is no longer enough on its own. An attacker has to beat two systems that share nothing.
You don’t need to know how either layer is built to check that both are working. These questions, and the answers you want to hear, are a good place to start.
A good answerNo. Only from our approved networks and devices, through Sentinel.
A good answerTwo: their account in our identity provider and their device certificate. Both on their last day, with a record of each.
A good answerYes, every privileged account uses a passkey or hardware key. Text-message codes aren’t accepted for admin access.
A good answerWe revoke its certificate and end its sessions. It can no longer connect, even with the right password.
A good answerA named person. It’s reviewed on a schedule, and every entry has a recorded reason.
A good answerYes. Sentinel blocks it, the attempt is logged, and someone reviews those logs.
Sentinel checks the network and the device, at the edge, before your application runs.
Sign-in checks the person, inside the application, through your identity provider.
Together they are two independent checks with nothing in common, so one failure is never enough.
Keep them separate: different owners, different credentials, each reviewed on its own schedule. If one is ever weakened, the other is still standing.