The Keys to Your Assets Are Probably in the Wrong Hands

She had been gone for seven months

Left the company on good terms, a warm farewell Slack message, a handover document that everyone agreed was thorough, a small leaving gift from the team. By the time she walked out of the office for the last time, she had already been interviewing at competitors for six weeks.

Seven months later, a routine cloud access review, the kind that should have been happening quarterly but had been deprioritised during a product launch cycle, surfaced something that stopped the Head of Security mid sentence.

Her account was still active, not just technically present in the system the way old accounts sometimes linger, but very active. With the same administrative permissions she had been granted eighteen months earlier when she joined as Head of Engineering. Access to the production environment, the customer data warehouse, the infrastructure that the company had rebuilt entirely since she left, on which it now ran three times the workload, processed five times the data, and served enterprise customers who had contractual expectations about who could reach their information. She had not used the access. There was no indication of malicious intent. She had simply left, and nobody had turned the key.

The account was disabled that afternoon. The access review was completed the following week. The gap analysis that followed found eleven additional accounts in similar states, former employees, a contractor whose engagement had ended, a vendor integration that had been deprecated six months earlier but whose service account still held the same permissions it had been granted on day one. Eleven open doors that nobody knew were open.

The company was fortunate. The story ended with an access review and a gap analysis. For many organisations, it ends differently with a breach investigation, a forensic report, and the specific, expensive recognition that the most dangerous access in their environment was not the access they knew about. It was the access they had forgotten.

The Problem That Feels Solved Until It Is Not

Identity and access management is one of those security domains that most growing startups feel reasonably confident about. The basics are understood. Users have accounts. Accounts have passwords. The more security conscious organisations have enabled multi factor authentication. The really organised ones have a directory service and a process for onboarding new employees.

And then the company grows. Engineers are hired faster than the access management process scales. Contractors are onboarded under time pressure with permissions that are easier to grant broadly than to scope precisely. Third party integrations accumulate service accounts that nobody fully inventoried because the integrations were set up by engineers who have since moved to different roles or different companies. The vendor whose platform you connected to your data warehouse two years ago still has an API key that was never rotated. The staging environment that was supposed to be isolated from production has access paths that were created during a late night debugging session and never removed.

None of this happened because anyone was careless. It happened because identity and access management is not a configuration you complete. It is a discipline you maintain and maintaining it under the consistent pressure of growth where the urgency of the next hire, the next integration, the next product launch reliably outcompetes the access review that has been on the agenda for three months is genuinely difficult in ways that security frameworks do not always make visible.

The result is an access landscape that bears increasingly little resemblance to the one that was intended where the principle of least privilege, the foundational idea that every user and system should have access to exactly what they need and nothing more, has drifted into something more like the principle of accumulated convenience. And accumulated convenience, in identity and access management, is the attack surface that threat actors find most reliably productive.

Why Identity Is Now the Primary Attack Surface

There is a reason that identity based attacks have become the dominant pattern in cloud security incidents. It is the same reason that a locksmith targets a house through the front door rather than the window, the door is easier, and it requires less noise.

In a well configured cloud environment, the traditional network perimeter attacks the vulnerability exploits, the SQL injections, the unpatched service vulnerabilities face meaningful defensive infrastructure. Firewalls, intrusion detection, vulnerability management programmes, WAFs. The defences are imperfect, but they are present.

The identity layer is different. Compromising a valid credential produces access that is, from the perspective of every downstream system, indistinguishable from legitimate use. There are no firewall rules that flag a successful login. No intrusion detection signature that fires on a correct password. The threat actor who holds a valid set of credentials is, functionally, inside the perimeter and the perimeter's defences are entirely behind them.

This is why phishing attacks targeting credential theft have become more prevalent and more sophisticated. Why credential stuffing the automated testing of credentials leaked from other breaches against your systems is a routine threat that every organisation with a web facing login interface faces continuously. Why social engineering attacks increasingly target the identity layer rather than the technical layer, because a convincing phone call to the IT helpdesk is faster and more reliable than finding and exploiting a software vulnerability. And it is why the access management posture of a growing startup, the hygiene of its identity estate, the comprehensiveness of its access reviews, the discipline of its offboarding process, the tightness of its service account governance is not a secondary security concern. It is the primary one.

What the Access Landscape of a Growing Startup Actually Looks Like

Let me walk you through the specific categories of access that accumulate in Series A and Series B organisations the ones that appear in gap analyses and access reviews with such consistency that they have become almost predictable.

The former employee accounts: Every organisation that has grown quickly has them. The offboarding process exists, HR sends the termination notification, IT disables the email account, the laptop is collected. What the process often does not catch is the full inventory of access, the cloud console account, the database credentials, the third party SaaS tools that the employee set up themselves and that IT never had visibility into, the API keys that were generated directly rather than through the identity provider.

The longer the gap between departure and comprehensive access revocation, the larger the exposure. And in organisations without automated offboarding workflows connected to a comprehensive access inventory, the gap is measured in weeks for email and months for everything else.

The over privileged accounts: The principle of least privilege is easier to state than to implement under growth pressure. When an engineer needs access to debug a production issue, the fastest path is to grant broad access and scope it down later. Later, in most organisations, does not arrive on schedule.

The result is an environment in which a significant portion of accounts hold permissions that exceed what their current role and current activities require. Developer accounts with production write access that was granted for a migration and never removed. Support team accounts with data warehouse access that was requested for one analysis and not revoked. Marketing team members with access to customer data systems they have not touched in six months but technically still need for the quarterly report.

Each of these accounts represents a blast radius the extent of damage a compromised account could cause. Over provisioned accounts have larger blast radii than they should. And in a well designed identity environment, the blast radius of any single compromised account should be bounded to the minimum necessary for the legitimate function that account was created to serve.

The service accounts and API keys: Service accounts the machine identities that applications and integrations use to authenticate to other systems are the most commonly neglected category in growing startup access management. They are created rapidly, often during integrations set up under time pressure. They are frequently granted broader access than the integration requires, because scoping precisely takes time that the urgent deployment does not allow. They are rarely included in access reviews. They are almost never rotated on a schedule.

The API key that was generated two years ago and embedded in a configuration file that has since been checked into a code repository. The service account created for a third party monitoring tool that was deprecated twelve months ago, whose credentials were never revoked. The integration that holds read access to the entire customer database when it only needs access to a subset of tables for the specific function it performs. Service accounts do not have human owners who leave the company and trigger an offboarding review. They persist until someone specifically identifies and revokes them and without a comprehensive inventory of machine identities alongside human identities, they persist indefinitely.

The privileged access that is not monitored: Administrative access of the accounts and roles that can modify infrastructure, manage user permissions, access all data, and make changes that affect the entire environment should be the most tightly controlled and most comprehensively monitored category in any organisation's identity estate.

In many growing startups, it is the least. Not because nobody thought about it, but because the engineers who built the infrastructure are the engineers who need administrative access to maintain it, and creating separate administrative identities, managing privileged access workstations, implementing just in time access for privileged operations, all of these are mature identity security practices that require investment in time and tooling that growth stage organisations frequently defer. The consequence is that administrative access is broader than it should be, less monitored than it needs to be, and when a privileged account is compromised, it is more consequential than any other category of access in the environment.

The Access Review That Most Organisations Are Not Doing

A comprehensive access review is the practice of systematically examining who has access to what across the entire organisation, every human identity, every machine identity, every privilege level, every system and verifying that the access is current, appropriate, and consistent with the principle of least privilege.

Most organisations know they should be doing this. Most are not doing it comprehensively, at the frequency that their growth rate requires, with the ownership and tooling that makes the findings actionable.

This is what a genuine access review produces that most organisations are not currently generating:

• A complete inventory of human identities: every account, across every system, including the SaaS tools that live outside the identity provider with the last login date, the current role, the permissions held, and whether that person is still employed by the organisation.

• A complete inventory of machine identities: every service account, every API key, every integration credential with the system that created it, the purpose it was created for, the access it holds, when it was last used, and whether the integration it serves is still active.

• A privilege mapping: a clear picture of which accounts hold administrative or elevated access, why that access was granted, what business function it serves, and whether it remains appropriate to grant it permanently or whether it should be implemented as just in time access for specific operations.

• A remediation list: the specific actions that need to be taken, accounts to disable, permissions to reduce, credentials to rotate, integrations to review and scope down.

This is not a quarterly checkbox. It is a programme that requires tooling, ownership, and a defined remediation process that ensures findings do not sit in a spreadsheet.

What Identity Security Looks Like When It Is Done Well

The organisations that manage identity and access well share several characteristics that distinguish them from the ones that are managing the consequences of not doing so.

They have an identity provider that is the single source of truth: Every human identity in the organisation authenticates through a central identity provider. Access to every system, cloud consoles, SaaS tools, internal applications is provisioned through the identity provider and revoked through the identity provider. Offboarding is one action, not a checklist of twelve separate systems.

They enforce multi-factor authentication without exceptions: MFA is not a recommendation, it is a technical requirement. Every account, including administrative accounts, including service accounts where technically feasible, authenticates with a second factor. Legacy systems that cannot support MFA are either upgraded or isolated, the exception list is empty.

They implement least privilege as a design principle, not an afterthought: Access is scoped at the point of provisioning, not reduced later. New integrations are audited for the minimum access they require before they are granted broad permissions for convenience. Elevated access for specific operations is time bounded and reviewed before renewal.

They have a machine identity programme alongside their human identity programme: Service accounts are inventoried. API keys are rotated on a defined schedule. Deprecated integrations are identified and revoked. The inventory is maintained continuously, not reconstructed periodically.

They monitor privileged access: Every use of administrative credentials is logged. Anomalous patterns, administrative actions at unusual times, from unusual locations, at unusual scale generate alerts that are investigated rather than deprioritised.

The Question That Changes Everything

I want to close with a question that I have found, in every access review I have been part of, to be the most clarifying thing a leadership team can ask.

If the most trusted person in your organisation, like the engineer who built the infrastructure, the executive who has been with the company since the beginning, the Head of Security herself, had their credentials compromised tonight, what could an attacker access?

Not the access they should have, the access they actually have, and how long would it take your organisation to detect that their credentials were being used by someone else?

The answers to those two questions describe your identity security posture more accurately than any compliance report, any access policy document, or any security questionnaire. They describe the actual blast radius of your most significant single point of failure. And they describe whether your detection capability is adequate to surface the misuse before it becomes the breach you are explaining to your customers.

The keys to your assets are in someone's hands tonight. The question is whether you know whose.