Permission Creep: How a Summer Intern's Login Can Haunt Your Database for Years
In the summer of 2019, a community college in the Midwest hired an intern to digitize enrollment records. Three years later, that intern's account — still active, still holding write access to the student information database — appeared in a routine security scan. The intern had graduated, moved to another state, and hadn't logged in once since August. Nobody had thought to remove the credentials.
This scenario plays out thousands of times a year across American organizations, from hospital systems in Ohio to logistics firms in Texas. It has a name among security professionals: permission creep. And for database administrators, it may be the most persistent, least glamorous threat on the books.
The Anatomy of a Forgotten Credential
Permission creep rarely announces itself. It accumulates through ordinary business events — a contractor brought on for a migration project, an employee temporarily elevated to cover a colleague's parental leave, a vendor granted read access during a software evaluation. Each grant makes sense at the moment it's approved. The problem is that organizations are structurally better at granting access than at taking it away.
The mechanics are simple. An intern needs to query a reporting database. A manager approves it. The project ends, the intern returns to campus, and the account sits in the directory like an unattended key under a doormat. In firms without automated deprovisioning, these dormant accounts can persist indefinitely — and attackers know it. Industry breach post-mortems consistently identify unused or over-privileged accounts as a common initial foothold, precisely because they tend to have weak or stale authentication and attract no monitoring.
Why Seniority-Based Audits Miss the Point
Most access reviews in US companies follow a familiar ritual: managers receive a list of their direct reports, confirm each person still needs their access, and sign off. The process is organized around org charts, not data.
The flaw is structural. A manager can confirm that a current employee's access seems reasonable without ever asking what that access actually exposes. Seniority tells you nothing about sensitivity. A junior analyst with a blanket SELECT grant on a table containing Social Security numbers, payment card data, or protected health information under HIPAA represents a far greater liability than a department head with tightly scoped read access to aggregate figures. Yet the audit form treats them identically.
A more defensible approach inverts the question. Instead of asking "who has access?" start with "what does this data require?" Classify the data first, then work backward to who should legitimately touch it.
A Practical Framework for Tiered Access
Organizations that get this right tend to converge on a small set of principles rather than elaborate bureaucracy.
1. Classify data by sensitivity, not by department. Establish three or four tiers — public, internal, confidential, and restricted — and map every database, schema, and table to one. Restricted tiers should include anything governed by regulation: HIPAA-covered health data, payment information under PCI DSS, and personally identifiable information subject to state privacy laws such as the California Consumer Privacy Act.
2. Grant by role, never by person. Individual grants are nearly impossible to audit and impossible to clean up at scale. Role-based access control, applied consistently, means offboarding becomes a directory operation rather than a forensic project.
3. Default to expiration. Any elevated access should carry a sunset date. If a contractor genuinely needs six months of write access, the credential should expire on day 180 unless someone affirmatively renews it. Expiration by default flips the burden: keeping access requires action; losing it requires nothing.
4. Separate read from write, and production from everything else. The college intern scenario happened because a single account could both read and modify production data. Least privilege is an old idea, but it remains the cheapest insurance available.
5. Log and review the restricted tier continuously. Quarterly reviews are too slow for data that triggers breach notification laws. Automated alerts on anomalous queries against restricted tables catch both attackers and honest mistakes.
Surviving the Contractor Offboarding
Contingent workers — contractors, temp staff, vendor personnel — are where access governance most often collapses. They sit outside HR systems, so the automated deprovisioning triggered by an employee's termination never fires. Their end dates live in procurement contracts, not in the identity platform.
The fix is procedural and unglamorous. Every contractor engagement should require a named sponsor inside the organization who is accountable for the account's lifecycle. Access should be provisioned only after the contract's end date is recorded in the identity system. And at offboarding, the sponsor — not the contractor — confirms revocation in writing.
For databases specifically, offboarding should include rotating shared credentials the contractor may have encountered. Service accounts, legacy connection strings, and embedded passwords in reporting tools are the classic residual risk; revoking a user account accomplishes nothing if the same password opens a service account that predates the current IT staff.
Making Revocation Routine
The organizations that avoid the forgotten-intern problem share one habit: they treat revocation as a scheduled maintenance task, not an incident response. Dormant account sweeps — flagging credentials with no successful authentication in 30, 60, or 90 days — should run automatically, with results routed to data owners for confirmation.
None of this requires new technology. It requires deciding that the default state of any credential is expired, and that access to data is a loan, never a gift. The intern who knew too much is only a liability if the organization never took the time to find out what the intern knew — and never bothered to take it back.
