The internal tool with no login is the risk you already own

The tool is not internal because you never published a link to it. It is internal when an identity check decides who may open it and a record shows what each person did. Until both exist, it is public with an obscure address — and the risk is already yours, because the data behind it is real. The exception is narrow: a page with nothing behind it, no personal data, no money, no customer names. Almost no business tool qualifies.

What does "internal" actually mean on the internet?

It means "we never linked to it", which is not a boundary. An unlisted address is a secret shared in chat, written into a document, saved in a browser on a laptop that gets sold, and typed in by a contractor who wanted to check something from home. Addresses leak quietly: in screenshots, forwarded emails, the referrer header of an outbound link, or a search engine's index of the login page.

A network rule helps only where the tool cannot ignore it — a VPN or an IP allowlist at the proxy, not a check the application runs on a value the client sends. Most small tools have neither, so their real state is: reachable by anyone who learns the address, protected by one password the team shares.

What is the minimum, short of a security programme?

Four things, in this order. They are not a programme; they are the floor below which you cannot answer basic questions about your own data.

1. A real identity per person. Not "admin", not the team mailbox. A named account with its own credential, so any action can be attributed and any access withdrawn without disturbing anyone else.
2. Roles that mean something. Read, write, approve, administer. Most tools need three or four. The test is whether a manager can restate the role in one sentence.
3. A record of who did what. Who created, edited or deleted a record, and when. Teams skip this and need it first: it is the only way to settle a disagreement about a price, a quantity or a deletion.
4. Revocation that works without a meeting. One action that removes access, immediately, for one person. If removing access means changing a password and telling twelve people, revocation does not exist — it is a negotiation.

The OWASP Authentication Cheat Sheet is the shortest credible reference for the mechanics underneath: how credentials are stored, what a session should look like, and why password reset is the weak point attackers actually use.

Why does one shared login make every log useless?

Because the log records the account, not the person. When three people use the same credentials, "admin changed the delivery price at 14:20" is a true statement about an account and a useless statement about a business. You cannot correct the behaviour, prove who was right, or defend the change to an owner.

The second cost is quieter: a shared password cannot give one person less access than everyone else. The new hire who only needs to look up an order gets whatever the person who closes the month has, because there is one key. That is how a read-only need becomes a write permission.

The third cost is rotation. A shared password cannot be changed when one person leaves without disrupting everyone, so it never is. A credential four people have held for two years is a convention, not a secret.

Question	One shared login	One account per person
Who changed this record?	The account	The person
Can access be removed today?	No, only rotated	Yes, in one action
Can a new hire be read-only?	No	Yes

Does read-only access need its own account?

Yes, and it is usually the cheapest improvement available. Read-only accounts cover most internal needs: a manager checking today's orders, an accountant pulling a report. Writing is a smaller group than reading in almost every business, and the gap is where accidents live.

Two habits keep it useful. Make the read view genuinely sufficient — if the only way to get a number is to edit a record, people will be handed write access and the restriction collapses. And separate export from edit: downloading a report is not changing it, but confusing the two is how customer lists end up on personal laptops.

What should happen the day someone leaves?

Access removal belongs on the same checklist as the keys and the laptop, with a name against it. When it lives in someone's memory, it happens late or not at all.

1. Disable the account rather than delete it, so the history stays attributable.
2. Rotate every shared secret the person could read, and replace it with per-person accounts.
3. Transfer ownership of records, saved views and scheduled reports to a named colleague.
4. Remove the account from integrations, mail rules and notification channels.
5. Write the date and the name of whoever did it beside the tool's documentation.

A decision procedure you can run this week

1. List every tool holding customer, supplier, price or payroll data. Include the ones a former developer built and the ones nobody remembers commissioning.
2. Open each one in a private window, logged out. If it opens, write down what it exposes. That list is your priority order, not your opinion.
3. Ask how many people share each password. Ask directly; the answer is usually higher than the manager expects.
4. Fix attribution first. For most tools that means individual accounts with two roles — read and write — before any role matrix.
5. Test revocation once. Disable a test account on a Friday, confirm it is refused on Monday.

Where this goes wrong

• The login page is added and nothing else changes. A form in front of a tool that trusts every request is decoration. The check must run on the server for every request that reads or writes data.
• Roles are copied from the org chart. Departments are not permissions: the warehouse supervisor and the purchasing manager may need the same rights, and the owner may need fewer than the accountant.
• The audit log exists and nobody reads it. A record nobody queries catches nothing. One monthly question — who changed prices last month? — turns the log into a control.
• Access granted for a project and never removed. Temporary access outlives the project, because nobody owns the end date.

What this does not cover

This is about who may reach the tool, not whether the tool is safe to expose. A correct login does not fix an injection flaw, an unpatched dependency or a backup nobody has restored; those need their own review. And it assumes the tool is yours to change: if it is a vendor's product, part of this is configuration you can request and part is not for sale.

We build internal tools that start with a named account per person, a role that means something, and a record of who changed what.