If you help run the non-clinical side of a digital health service, you probably juggle logins more than you would like. Staff accounts, remote-visit tools, scheduling apps, reporting scripts: each one needs someone behind it who is supposed to be there. That upkeep has a name, IdentityOps, and this list shares eight habits that make it manageable. It is administrative background, strictly non-clinical, with no medical advice and no statement about any specific service.
1. Start from the HR list, not from the tools
The cleanest way to know who should have an account is to ask the people department. When the HR record is the trigger for joining, changing role and leaving, everything else can follow from it. The Atlas page on IdentityOps puts this joiner, mover and leaver flow at the centre of its scope, so it makes a sensible first habit.
2. Count a departure only when it is finished everywhere
Switching off the main account is step one of several. A good routine also cuts open sessions, tells each connected application, and notes the time at every stage. Report the percentage of leavers fully closed across all tools, not just the first switch. The two figures can differ more than anyone expects.
3. Give every application an owner
Think of it as a guest book for your software. If you cannot say who looks after a tool, nobody is watching its users.
Keep a simple register: the tool, a named owner, how people sign in, and whether it can accept automatic removal. Applications with their own local user lists are the usual troublemakers, so flag them early and set a manual removal deadline for each.
4. Choose sign-in proofs that cannot be tricked
Texts and tap-to-approve prompts feel secure, yet a convincing fake page can collect them. The Atlas follows national guidance in treating only hardware-bound authenticators, meaning FIDO2 security keys and smart cards, as phishing-resistant. Roll them out in a sensible order: the people who administer the sign-in system first, then anyone with email, remote or payment powers, then everyone else.
5. Write a recovery script for lost devices
This one is easy to skip because it feels like a rare event. It is not rare, and help desks improvise when no script exists. Improvisation is exactly what impersonators count on, especially when a caller sounds stressed and in a hurry.
Everyone loses a phone eventually. Decide ahead of time what the help desk does. A lost second factor might be replaced through a second enrolled method; a harder case needs a manager to confirm on a live call before a one-time pass is issued. Whatever the path, the person should receive a notification afterwards, so surprises surface fast.
6. List the robots
Scheduled exports, integration keys and automation tokens are identities too. Give each a documented purpose, an owner and an end date, and prefer credentials that expire quickly. A monthly report of anything nearing expiry keeps these from being forgotten. When one is retired, disable it, leave it idle for a short spell in case something complains, and only then remove it for good, saving a note of what you did.
7. Sweep for dormant accounts
Quiet accounts are not harmless accounts. A login that has not been touched for months is precisely the sort nobody would notice being misused.
Pick a window between ninety and a hundred eighty days and review logins nobody has used. Exclude people on approved leave, emergency accounts, and machine identities whose owners recorded a longer cycle. The sweep gently tidies the pile and catches the odd login that slipped through the leaver flow.
8. Rehearse, then measure
A plan on paper is a hypothesis. Each quarter, run a leaver drill with a volunteer and watch what stays alive. Review the trust settings between your sign-in hub and other applications at the same time. The Atlas proposes a calendar you can pin up: a daily comparison of rosters, a weekly look at a few recovery cases, a monthly list of expiring robot credentials, and the quarterly drill.
Bonus: know what you are not covering
It is tempting to stretch a new practice until it swallows every security task nearby. Resist that. A tight scope is easier to staff and easier to measure.
IdentityOps concerns the existence of each account and the evidence behind it. Deciding which person may open which module is a separate design job, and so is the process of requesting extra rights. Naming those edges prevents turf wars and keeps your own list short.
Where to read next on this site
If your team supports remote consultations, you might enjoy a clinical-context overview of how telehealth fits into cardiology services, which shows how many software touchpoints a single patient contact can involve. A companion entry on what digital tools mean within cardiology gives the wider landscape. Both are general reading rather than recommendations.
A word on numbers before you go. Whatever you measure, choose targets people can recall without a slide: for instance, a few hours to disable a leaver’s main account, a day to remove them from every other tool, three months before a silent login gets switched off, and a ninety-day ceiling on how old a machine credential can get. These example targets come from the Atlas and are a starting point, not a rule; adjust them to your risk and your size.
Pick one habit this week. The register is a good candidate, because it costs nothing and reveals the rest of the work. Once it exists, the other seven stop feeling abstract, since you can see exactly which application would fail each test.
