Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

The instructive intrusions of the season share a shape: the authentication failed, not the firewall. Here's the afternoon review that counts every door your organization exposes — and turns the count into a signed record.

---

The pattern with no forced entry in it

Read this month's actively-exploited list with one question in mind — what actually failed? — and a theme emerges. A screen-sharing service that authenticated a network attacker without valid credentials. A collaboration platform whose security feature could be walked past after a public proof-of-concept dropped. A management console, weeks earlier, whose login could be skipped entirely via an alternate path. And in the same season, a seven-figure dump of contact records — name, email, address, phone — whose main criminal application is making the next call to a help desk sound exactly like the user it claims to be.

No malware had to beat your EDR in any of those stories. The doors did what they were configured to do. The configuration was the finding.

Which leads to an uncomfortable reframe: your perimeter is not a firewall diagram. It's the set of every internet-reachable place that accepts a credential for your organization — or for each client, if you're the MSP. And in most shops, that set has never been written down.

You can't lock a door you haven't counted

The review starts with an inventory, because every later question is per-door. Twelve categories jog the memory:

1. Identity provider / SSO — the front desk itself
2. Email & webmail — including the legacy paths (OWA, ActiveSync, basic auth)
3. VPN portals & remote-access gateways
4. Firewall / network-gear admin interfaces
5. RMM & remote-support tooling — last week's master key cabinet
6. Hypervisor & infrastructure management — vCenter, iLO/iDRAC, cloud consoles
7. File / intranet / collaboration platforms
8. SaaS admin consoles — PSA, billing, backup, the password manager
9. Remote desktop & screen sharing — RDP, VNC, OS-native sharing
10. Break-glass & emergency accounts
11. Service accounts & API keys — doors with no human attached
12. The help desk's reset procedure — a door that answers to a voice

One row per door: what it is, who uses it, what it accepts, who owns it, when it was last checked. If producing that table takes more than an afternoon, that fact is itself the first finding.

"We have MFA" is a per-door claim

Here's where last week's management-plane review and this week's shake hands. The five console questions asked is MFA enforced on the console itself — because a console with local accounts is indifferent to how good your identity provider's MFA is. This week generalizes it. For every row in the inventory, mark exactly one:

• ON THE DOOR — the service itself enforces a second factor, local accounts included.
• UPSTREAM — MFA lives at the IdP; anything the door authenticates locally walks past it.
• NOWHERE — a password alone opens it.

Then two follow-ups per door: can any account skip it? (service accounts, legacy protocols, app passwords) and does this door hold accounts the IdP has never heard of? The org-level sentence "we have MFA" aggregates away exactly the information an attacker cares about. The matrix exists to de-aggregate it.

The side doors

Most gaps the matrix finds fall into a short, familiar list — the paths that skip the second factor:

• Legacy mail protocols still answering basic auth
• App passwords and long-lived tokens that outlive their owner's MFA
• Vendor and default accounts that shipped with a product and still resolve
• Break-glass accounts with no compensating alert on use
• Admin interfaces exposed to the whole internet where an allowlist would do
• API keys embedded in scripts older than the last rotation
• The MFA exception that was "temporary" two migrations ago

Close what you can in the afternoon. For what you can't, write down the reason and an owner — an accepted risk with a name and a date is a decision; the same gap undocumented is just exposure.

The human door

The password reset flow is an internet-reachable authentication endpoint. It runs on a human, under social pressure, and its verification data — the things a caller is asked to prove — is precisely what large contact-data dumps put in criminals' hands. So the script is short and strict: never authenticate on knowledge alone; call back on the number already on file, never the one the caller offers; verify through a second channel the account owner controls; allow no urgency exceptions, because manufactured urgency is the technique; and log every reset — who asked, how verified, who approved, when.

Five lines, printable. It converts the softest login you own into one of the most defensible — and the log converts it into evidence.

The record is the deliverable

Same rule as restore week and console week: every claim gets a number and a date. The afternoon ends with one page: doors enumerated, MFA state per door, paths closed, exceptions accepted (with owners), script deployed, next check booked. "Twenty-two doors, MFA enforced on nineteen, three legacy paths closed, Aug 27, J.R., re-check November" is an artifact — the kind cyber-insurance applications and client questionnaires increasingly expect. "We're pretty locked down" is a mood.

The whole thing, packaged free

The Login Surface Kit (Gatorbyte #010) bundles the review: the 12-category inventory worksheet, the MFA coverage matrix, the legacy-path kill list, the help-desk verification script, and the evidence log — free: thesecuritygator.gumroad.com/l/gb010-login-surface-kit.

One afternoon. Twelve categories. One signed page either way it lands. Because a door you haven't counted is a door you can't lock.

---

This is a review format, not managed security services — and not legal, compliance, or audit advice. Authentication capabilities vary by product and license; verify against your vendor's current documentation. If a review turns up evidence of compromise, follow your incident-response plan.