The log-on procedure, decided in code.
ISO 27001:2022 A.8.5 (secure authentication) expects secure authentication technologies and procedures, matched to the access-control policy and what a given system's access requires. In practice, the part of that most often decided in a pull request is the log-on procedure itself: limiting unsuccessful log-on attempts, not displaying or transmitting a password in the clear, and not silently downgrading to a weaker check once a stronger one is required for a given path. That procedure is implemented in code, not policy, which makes it a pull-request decision like any other.
The shapes the same control failure takes.
A.8.5 rarely breaks by removing a login form. It breaks when the procedure around log-on quietly gets weaker. The recurring shapes:
Failed-attempt limiting is removed
A lockout or throttle after repeated failed log-ons is dropped or loosened, so an attacker can retry a password or code as many times as they want.
A weaker fallback path is added
A new path (a legacy endpoint, a support override, a 'trouble signing in' link) reaches the same account through a weaker check than the primary log-on requires.
A password or code is shown or sent in the clear
A password, one-time code, or reset token is displayed back, echoed in an error message, or logged in plain text during the log-on attempt itself, instead of staying protected.
An idle session is never terminated
A timeout that logged an inactive session out is removed or extended indefinitely, so an authenticated session left unattended stays open rather than requiring the user to log on again.
Log-on attempts stop being recorded
The event that a log-on attempt succeeded or failed stops being recorded, so there is no record to review for a run of failed attempts against an account.
A login lockout removed to fix a support complaint.
A handful of users are getting locked out after mistyping their password a few times, and support is fielding the complaints. The fastest fix is to remove the attempt counter so nobody gets locked out again. It works: nobody is locked out, and neither is a script trying every password in a breach list against the same account.
async function attemptLogin(email, password) {- const attempts = await getFailedAttempts(email)- if (attempts >= 5) return locked() const ok = await verifyPassword(email, password)- if (!ok) await recordFailedAttempt(email) return ok ? grantSession(email) : denied()}Removing the failed-attempt counter removes the attempt-limiting control visible in this login path, so a mistyped password and an unlimited-guess credential-stuffing script against the same login are now handled the same way. A.8.5 (secure authentication) expects unsuccessful log-on attempts to be limited. Keep the limit, and fix the false-positive lockouts with a cooldown or progressive delay instead of removing the check outright.
Log-on procedure is checked as a procedure, not a login screen.
An auditor looks at whether the log-on procedure actually limits abuse, not just whether a login form exists: attempt limiting, no silent downgrade to a weaker method where a stronger one is required for that path, no password shown or sent in the clear during log-on, and log-on attempts recorded. A lockout quietly removed, a legacy endpoint left reachable, or a session timeout removed so an idle session stays authenticated is the kind of gap that surfaces, and it usually arrives as a well-intentioned fix to a support complaint. The diff to the auth code is where it is decided.
A review, not your identity provider.
heygrc flags changes that touch A.8.5 and cites the control so the fix happens in the pull request. It does not run your login flow or issue your sessions. It catches the moment a change weakens the log-on procedure itself, at the diff.