Login hardening for an internal admin suite after a penetration test

An annual penetration test against the internal admin tools produced a report with several findings clustered around authentication: no rate limiting worth the name, a password reset flow that told an attacker whether an account existed, session behaviour that did not match the policy the company had written down, and a set of service accounts with interactive login enabled that nobody had used in years. Internal tools get less attention than customer-facing ones, and these had grown from three applications to eleven behind a shared login without anyone owning that login. The findings had a remediation deadline attached.

Backend engineer, brought onto a short remediation team of three for about four months, working directly to the security lead who had commissioned the test. This was a fix-and-close engagement rather than a product one: the deliverable was a retest with the findings closed. I took the authentication findings; the other two took the authorisation and infrastructure ones. It was the first time I had worked to a report rather than a backlog and I found it clarifying.

I owned all the authentication remediations. That was rate limiting and lockout behaviour done properly rather than as a counter, making the reset flow respond identically whether or not an account exists, bringing session lifetime and idle timeout in line with the written policy, and disabling interactive login on nineteen service accounts after tracing what each one actually did. I also wrote the tests that assert these behaviours, because a finding fixed without a test is a finding that comes back, and I said so in the retest document.

I pushed to fix the underlying pattern rather than the eleven instances. Each application had its own login handling copied from an older one, so the report technically described eleven sets of the same bug; remediating each in place would have been faster to close and would have guaranteed the twelfth application repeats it. Instead we consolidated onto one authentication path and migrated the applications, which took longer and needed the security lead's support to hold the deadline conversation. I also chose to keep the uniform reset response even though it makes support's job harder, and wrote the support team a script for the calls it causes.

The remediation deadline came from the test report and an internal policy, not from us, so scope was cut rather than dates moved — two lower-severity findings were formally accepted as risk with a date instead of being fixed, which felt uncomfortable and was the right call. Some of the admin tools are used by teams whose work cannot stop, so migrations to the shared login path happened per application after hours with the old path kept for a week. And I could not test the rate limiting realistically in a lower environment, so the final validation was a controlled exercise in production with the security lead watching.

All authentication findings closed at retest, including the two that had been carried over from the previous year's report, which was the sentence the security lead cared about. Eleven applications now share one login path, so the next finding is one fix. The nineteen service accounts turned out to include three that were genuinely in use by scheduled jobs — traced, moved to non-interactive credentials, and documented. The support script exists because I made the reset flow less helpful on purpose, and I still think that trade is right.

The security lead ran interference on the deadline and let me argue for the slower, better fix, which not every security lead would. The two other engineers on the remediation team took everything that was not authentication so I could stay in one area. The support team lead reviewed the reset messaging and rewrote it into something a person can act on without it revealing anything.