Show the login they did not make

Someone signed in, or someone tried, and it was not the person who owns the account. Tonight, three proofs, in a console you administer. Name that sign-in: which account, when, whether it was accepted, and the source the log actually stored. Show the attempt refused, or show the session it opened is no longer accepted. Then show a sign-in the owner completes still succeeds, and a different account's ordinary sign-in still succeeds. If the name, the refusal, or the other success needs the person who built the product, you have not shown a login. You have a story about a feeling.

This is one sign-in on one account. It is not the afternoon you already know who should be signed out. End the session they still hold lists that person's sessions and ends those secrets while someone else stays in. Ending a session does not reconstruct the sign-in that created it, and a sign-in you can name does not, by itself, kill the secret. It is not a quota. Cap one account, leave the rest up stops one identity from spending past what you sold, and leaves the next identity working. A refusal of the next token is not a record of who authenticated. It is not the words they were shown when they agreed to a purpose. Show the consent they gave is that text, the act, and the time. An agreement can be real while the sign-in was someone else. A customer who already saw another customer's data is a different first hour, and a password reset does not close it.

None of what follows decides whether a testing category or a breach report covers your product, and none of it is legal advice. The pages below are the clearest public statements of how often authentication weaknesses show up in a testing dataset, and of how often stolen credentials were an initial access vector in one year's investigations. They do not tell you which control binds a Virginia company. They do not replace the lawyer you call when the letter is from counsel. They do tell you the shape of a proof a founder can perform this week, which is a product question.

The catalogue that names this class of bug kept its rank and changed its label. OWASP Top 10:2025, A07 Authentication Failures, "maintains its position at #7" and the introduction says the previous name was Identification and Authentication Failures, changed "to more accurately reflect the 36 CWEs in this category." The same paragraph says the increased use of standardized frameworks "appears to be having beneficial effects on the occurrences of authentication failures." That sentence is not a rate. The introduction prints an average for other categories and does not print one here: broken access control 3.73% of applications, across 40 CWEs; misconfiguration 3.00%, across 16 CWEs; cryptographic failures 3.80%, across 32 CWEs. None of those three is A07, and none of them is the table below (OWASP, Introduction, Top 10:2025).

A07's own score table is a different row. 36 CWEs mapped. Maximum incidence 15.80%. Average incidence 2.92%. Maximum coverage 100.00%. Average coverage 37.14%. Average weighted exploit 7.69. Average weighted impact 4.44. Total occurrences 1,120,673. Total CVEs 7,147 (OWASP, A07:2025 Authentication Failures). 15.80 is not 2.92. 2.92 is not the introduction's 3.73, not 3.00, and not 3.80. Maximum coverage 100.00% is a cell. The A07 page does not say that 100% of applications had an authentication failure, and the cell is not that sentence. Average coverage 37.14% is not incidence. 7.69 is not 4.44, and neither is a share of applications. 1,120,673 is not 7,147. 7,147 is not 36.

Read the method before you borrow a cell. The introduction says they ranked twelve categories on contributed data and allowed two to be promoted by a community survey, because testing data looks at the past. It says A03 Software Supply Chain Failures was overwhelmingly voted a top concern, and that A09 was again voted into the list. It does not call A07 a survey promotion. A07 prints a score table, which is why it sits with the testing data rather than with the two promotions. They ignore how often a weakness repeats inside one application: four instances and 4,000 instances count the same, because manual testers often list a weakness once and automated tools list every instance. They analyzed 589 CWEs, up from almost 400 in 2021 and about 30 in 2017. 248 of them sit in the ten categories. The MITRE dictionary had 968 at release. 589 is not 248 is not 968. They capped a category at 40. A01 is at the cap. A07 has 36. A03 has 5. 36 is not 40 is not 5. Contributors gave data for "over 2.8 millions applications," their plural. That phrase is not 1,120,673 occurrences and not 7,147 CVEs.

The exploit and impact cells are CVE scores, not login rates. The introduction says there are about 175k CVE records mapped to CWEs, up from 125k in 2021, drawn from nearly 220k CVEs. 160k had CVSS v2 scores, 156k had v3, and 6k had v4. Many CVEs have more than one score, so those three can total more than 220k. 643 unique CWEs were mapped, up from 241. In CVSS v2, exploit and impact could each reach 10.0, and the formula then weighted them 60% and 40%. In v3 the maximums are 6.0 and 4.0. "Almost a point and a half" and "nearly half a point" are the introduction's phrases for how the averages moved between those two scoring systems. They are not 7.69 and they are not 4.44. Do not cite either phrase as A07's row.

What the A07 page says to do is a list, and only some of the lines are this proof. Where possible, enforce multi-factor authentication. Encourage a password manager. Do not ship default credentials, particularly for an admin. Check new passwords against "the top 10,000 worst passwords list." Check new accounts and password changes against known breached credentials. Align length, complexity, and rotation with NIST 800-63b section 5.1.1, which the page names and does not quote. Do not force people to rotate passwords unless you suspect a breach; if you suspect one, reset immediately. Use the same message for every failed outcome, and the page's example is "Invalid username or password." Limit or delay failed attempts, and do not build a denial of service while you do it. Log the failures and alert an administrator. Issue a new session identifier after login, keep it out of the URL, and invalidate it after logout, idle, and an absolute timeout. The invalidation is the session article. This page is the sign-in you can point at. A log you do not have is not the alert. An alert you forwarded is not the refusal.

The page's three scenarios are shapes, not your log. The first is credential stuffing, lists of known username and password pairs, and what the page then calls "hybrid password attacks credential stuffing (also known as password spray attacks)," with the examples Password1!, Password2!, Password3!, and a year rolled forward on a seasonal password. The parenthesis puts two names on one sentence. A list of pairs from other sites is not the same object as guessing the next increment on one account, even though the page groups them. The second scenario says most successful authentication attacks still come from passwords as the only factor, and that rotation and complexity rules push people to reuse and to weaken. The third is a session left open: a public computer, a closed tab, no logout, or a single sign-on that does not end every application on the way out. That third shape is the session article. Do not spend this hour on it if what you cannot show is the sign-in itself.

A national investigations report measures a different population, and it is already quoted on this site for a different percentage. Verizon's 2025 Data Breach Investigations Report is the 18th edition. The team analyzed 22,052 incidents, of which 12,195 were confirmed breaches. Use of stolen credentials is 22%, down from 31% in the prior period. Exploitation of vulnerabilities is 20% of "all breaches we analyzed," a 34% increase from the prior report. Phishing is "around 15%." The figure those vectors are drawn on is captioned for non-Error, non-Misuse breaches, n=9,891. 22 is not 20 is not 15. 34% increase is not the 20. The same report says the 2024 edition's stolen-credential figure, once the vectors were made mutually exclusive, moved from 38% to 31%. 38 is not 31, and 31 is not 22. Do not add 22, 20, and 15 and call the sum a finding. Do not multiply 22% by 12,195 or by 9,891 or by 22,052 and replace the 22. The 22% that is edge devices and VPNs, as a share of the exploitation action, grew from 3%, which they call almost eight-fold. That 22 is not the credential 22. Almost eight-fold is their phrase. It is not 3, and it is not a count of your logins (Verizon, 2025 Data Breach Investigations Report).

Three other percentages in the same report are easy to grab because they look like the credential line. Human involvement is 60% this year and 61% last year. The share of breaches with a third party involved doubled from 15% to 30%, and that pair is already the point of tell the client what still works. It is not an authentication rate. Inside the infostealer logs, a different 30% of compromised systems were enterprise-licensed devices. That 30 is not the third-party 30. 46% of the systems in that analysis that held corporate logins were non-managed and held both personal and business credentials. 46 is not 30. Of ransomware victims whose domains were compared with those dumps, 54% had the domain in the dump and 40% had a corporate email address in the credentials. 54 is not 40, and neither is 22. Verizon sells communications and security services. The figures are that report's investigations, not a sample of startups, and not the probability that the sign-in in front of you was stolen.

Do the three proofs on one real sign-in, in the log the product actually writes. First, the name. Open the record: the account, the time, accepted or refused, and the source field that is really there. An address, a client name, an identity-provider subject, or a blank. A blank is a result. Write it down. A teammate who says "that wasn't them" has described a suspicion. You have not named the sign-in until the row is on a screen you opened. Second, the stop. If the row is a refusal, show the refusal. If the row is an acceptance, end the session it created and show the old secret refused, which is the neighboring article's drill, and keep this row beside it. Deleting the row so the screen looks clean destroys the proof. Third, the two successes. You watch the owner complete a sign-in you would recognize, and it works. You sign in as a different account that nobody accused, and it works. If the only control that quiets the bad row is a switch that locks every account, you have taken the product down. That is allowed in an incident. It is not this proof.

Three moves feel like the proof and are a second problem. Forcing a password reset on the whole tenant, because the tool you were given has no single-session path, and then describing the outage as care. Asking a model whether the login was legitimate, which edits a prompt and leaves the log. Emailing the vendor a screenshot of the dashboard home, which shows that a product exists and does not show the row. The first punishes the people who did not sign in. The second is a fiction. The third is a status line. A price they accepted is show the price they accepted. The amount is not the authentication. A mailing list you can suppress is show the unsubscribe they sent. An address absent from a campaign is not a sign-in.

The path is ordinary when an admin can see one account's authentication events without reading the next person's mail to do it. Gigbase is a multi-tenant workspace with secure authentication, subscription plans, and role-based access for agencies, admins, and team members, and a dedicated admin dashboard. The shape that matters here is an admin, in an account you administer, who can open one account. That case is not a sign-in ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the admin screen deletes the tenant, you do not have this proof. You have a kill switch.

There is a version of this morning where hiring the path is the wrong purchase. Nobody can sign in, because the product does not have accounts yet. You have no product. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top saas development company. That page is criteria. It does not rank anyone, including us. The only fact you have is a percentage from a report, and there is no log to open. A percentage is not a row. A customer has already seen another customer's data. Showing one foreign sign-in does not close a leak. Or you wanted a lawyer to say whether a statute applies. Hire the lawyer.

When the sign-in is real and the console cannot show it, the missing object is specific. An admin action, in an account you administer, that shows one sign-in, ends or refuses it, and leaves the owner and a different account able to sign in. A startup software development company that expects this will have put that action next to the rest of account admin, before a stranger's success is the way you discover the vendor owns the log. One that needs a call in order for you to see who authenticated is telling you who holds the front door. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which system records sign-ins, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that a breach report applies, and they are not a rate.

A version the lockfile resolved, and a model identifier on one request, are different stops: name the package the lockfile pinned and name the model the request hit. Do not record either on this page. A dependency tree is not a sign-in. A model id is not an authentication event. A factor the account enrolled is a different binding, show the factor they enrolled. A sign-in is not the authenticator.

Before you tell them the account is theirs again, do the three proofs and write the time. Name the sign-in. Show it refused, or show the session it opened is dead and the row still exists. Show a sign-in they make, and a sign-in on a different account, still succeeding. Do not reset the tenant to avoid the log, and do not ask a model who logged in. A report can tell you how often stolen credentials appear in other people's breaches. The row is the page you can defend.