The Account Nobody Remembers Creating

Every system you use has a list of who can get in. Nobody has read it since it was set up.

On that list is a login created in 2020, by somebody who left in 2022, which was used last week.

⚠️ That last part is the interesting one. A dormant old account is untidy. An old account that is still being used means something is running that nobody has described to you.

The short version

• Old logins are normal. Old logins still in use are the ones to look at
• The question is not "who made this" but "what can it do, and when was it last used"
• A login that is used but unexplained usually means an automated job, not an intruder
• Do not delete first. Something may depend on it and the breakage will be silent
• Find out what it does, then decide

The two lists worth having

List	What it tells you
Who can get in	The size of the problem
When each one was last used	Which ones are real

⚠️ The second list is the one nobody has. Without it every old account looks the same, so nothing gets done about any of them.

One: last-used is the whole diagnosis

Most systems record it. Almost nobody looks.

Never used         - created and forgotten. Safe to close
Last used in 2022  - matches somebody who left. Close it
Last used last week - something is running. Find out what

⚠️ The third is not necessarily wrong. It is unexplained, which is a different problem and often a more useful one.

What to ask for

"Can I see the list of logins, with the date each one was last used?"

⇒ One question per system. If the answer is "we can't see that", that is itself worth knowing — it means access can never be audited.

Two: what it can do matters more than who made it

An old login with limited permissions is a tidiness issue. An old login that can do everything is not.

Read-only          - low
Can change prices  - medium
Can issue refunds  - high
Can do anything    - treat as urgent

⚠️ Sort by what it can do, not by how old it is. A six-month-old account with full access beats a six-year-old one that can only view the rota.

⇒ Related: who can say stop.

Three: the one that is used but unexplained

This is the case worth walking through, because the instinct is wrong.

We found one of these in our own setup. A login created in 2020, still active, used five hours before we looked. Nobody currently working had created it.

Instinct   somebody has our credentials - lock it now
Reality    almost always an automated job nobody documented

⚠️ Both are possible, and the response to each is different, so establishing which comes first.

How to tell them apart without touching anything

Is the usage at the same time every day?
  Same time     ⇒ a scheduled job
  Scattered     ⇒ a person, or something event-driven
How much does it do each time?
  A consistent amount ⇒ a job
  Varying             ⇒ a person

⇒ Two readings from records you already have. Neither requires changing anything, which matters because of the next section.

Four: why deleting first is the wrong move

The instinct when you find an unexplained active login is to cut it off.

You disable it
Something stops
Nobody notices, because nobody knew it was running

⚠️ The breakage is silent by definition. If it were visible, somebody would have told you about the job in the first place.

The order that works

One   Find out what it does (readings only)
Two   Find out who depends on it
Three Then decide: keep, replace, or close

⇒ Do not skip one. Locking something you cannot describe means you also cannot describe what broke.

⇒ On changes that quietly break other things: the check that quietly stopped.

Five: the names are not evidence

A small trap, and an easy one.

An old login called "j.smith"
A forwarding address called "jsmith@..."
⇒ tempting to treat as the same person

⚠️ A similar name proves nothing. Two things named alike can be unrelated, and two things named differently can be the same. Judge by what the records show was done, not by what things are called.

⇒ We hit this exactly — a login and an address with near-identical names, and the records showed the login had never done the thing we were investigating.

Six: when somebody leaves

Most old accounts exist because leaving has no checklist.

Their key comes back
Their uniform comes back
Their logins stay forever

The leaving list worth having

One   Which systems did they have access to?
Two   Which are shared logins they knew the password to?
Three Anything scheduled or automated they set up?

⚠️ Three is the one that causes the trouble later. A job somebody set up under their own login keeps running until it breaks, and then nobody knows what it was for.

⇒ Related: who did it is not what they did.

Seven: shared logins

The other half of the problem, and the more common one in this trade.

One login, everybody knows it
⇒ every record says the same name
⇒ "who did this" can never be answered

⚠️ This is usually a deliberate convenience and it is worth naming the trade you are making. Shared access means faster nights and no accountability. Pick knowingly.

The compromise that usually works

Shared login for things everybody does (viewing the rota, taking bookings)
Individual logins for things that need a name (discounts, refunds, price changes)

⇒ You do not need individual access everywhere. You need it where the record has to answer "who".

Numbers worth keeping

One   For each system: number of logins that can get in
Two   How many were last used more than 6 months ago
Three How many are used regularly but belong to nobody current
Four  How many can do money-level things

⚠️ Three is the one to act on first, and it is almost never zero.

The card for the office

────────────────────────
  An old login

  1. When was it last used?
  2. What can it do?
  3. Used recently but nobody's? - find what it runs
  4. Do not disable before you can describe it.

  A similar name is not evidence.
────────────────────────

Common objections

"We'd know if someone had access"

⚠️ You know who you gave access to. The list is what access exists, and the two drift apart over years.

"It's been like that for years, it's fine"

⇒ Years of nothing happening is not the same as nothing being possible. Duration is not a control.

"Just delete anything old"

⚠️ Delete the unused ones, yes. The used ones need describing first, or you will be diagnosing a silent failure next week.

"Our provider handles security"

⇒ They secure the system. Who has a login is your list, and only you know who still works there.

"We're too small for access control"

⇒ Then you are small enough to read the list in ten minutes. Size is an argument for doing it, not skipping it.

What to do this week

One   Ask each provider for the list of logins with last-used dates.
Two   Mark anyone who has left.
Three Close the ones that are unused. That is the easy half.
Four  For any used recently but belonging to nobody: find what it runs first.
Five  Add "logins" to whatever you do when somebody leaves.

Summary

• Old logins are normal; old logins still in use are the ones that matter
• Last-used dates are the whole diagnosis and most systems have them
• Sort by what it can do, not by age
• An unexplained active login is usually an undocumented job
• Describe before disabling — the breakage is silent
• Similar names are not evidence of the same thing

Nobody remembers creating it, which is exactly why it is still there. The list outlives everyone on it.