Skip to main content
Style:
Size:

Part 3: Non-Human Identities (The Hidden Army)

Chapter 6: Service Accounts, APIs, and Bots: The 45x Problem

We are now leaving the loud, messy world of Human Workloads and entering the territory where most corporate security programs silently fail. We are moving deep into the server racks.

If you walk into a Fortune 500 company and ask the Chief Information Security Officer (CISO), "How many employees do you have?" they will confidently check the HR dashboard and say, "Exactly 10,492."

If you ask that same CISO, "How many Service Accounts, API keys, and bots do you have?" they will pause, look out the window, and say, "Uhh... probably a few hundred thousand?"

This is what the industry calls the 45x Problem. Averages show that for every single human employee in a modern enterprise, there are 45 Non-Human Identities (NHIs) operating in the background.

What exactly is an NHI? It is any identity that isn't a meatbag. It is the automated script that backs up the database at 2:00 AM. It is the API key that allows your billing software to talk to Stripe. It is the service account your developers use to deploy code to your cloud infrastructure.

Why Are Non-Human Identities So Dangerous?​

NHIs represent the ultimate security paradox: They have the highest level of access on the network, but the lowest level of oversight. They are fundamentally broken in three ways:

  1. They do not have MFA: You cannot send a push notification to a Python script. When a bot needs to log in, it relies entirely on a static password, a long-lived API key, or a certificate. If an attacker steals that string of text, they instantly become the bot.
  2. They are wildly over-privileged: Developers are notoriously focused on speed when building scripts. Instead of taking three days to figure out exactly which 3 micro-permissions a bot needs, they just grant the bot Domain Admin or Root rights so the script doesn't fail during testing. They promise to fix it later. They never do.
  3. They are immortal: When a developer quits, HR shuts off the human's account on Friday at 5:00 PM. But the script that developer wrote 4 years ago? It is still running on a forgotten server, using a service account with God-mode privileges.

Interactive Simulator: The NHI Sprawl Simulator​

Visualize how quickly the attack surface expands when bots are left unmanaged over a 5-year timeline:

The NHI Sprawl Simulator

Visualize how rapidly unmanaged service accounts and API credentials multiply over 5 years.

Loading Simulator...

The 5 Pillars for Taming the Bots​

To secure this hidden army, we cannot use the same playbook we used for humans. We have to rethink our IAM pillars entirely.

1. People (Ownership is Mandatory)​

A bot does not have a pulse, which means it cannot be held accountable. Therefore, every NHI must have a human sponsor.

  • The Process: If Bob creates a service account, Bob is the documented owner. If Bob leaves the company or transfers departments, the IAM system must automatically alert Bob's manager: "You have 7 days to assign a new owner to this service account, or we are shutting it off."

2. Process (Discovery and Lifecycles)​

You cannot protect what you cannot see. The first step in any NHI program is Discovery. You must relentlessly scan your network, your code repositories (like GitHub), and your cloud environments to find every single hardcoded API key and orphaned service account.

  • Once discovered, you apply a strict lifecycle: Request ➔ Approve ➔ Provision ➔ Rotate ➔ Decommission.

3. Technology (The Secrets Manager)​

You cannot expect developers to manually log in and change the passwords for 100,000 bots every 30 days. You need a Secrets Manager (like HashiCorp Vault, CyberArk, or AWS Secrets Manager).

  • Instead of a bot having a password saved in a text file, the bot asks the Secrets Manager for permission. The Secrets Manager verifies the bot's identity, generates a temporary, dynamic password, hands it to the bot, and then destroys it 60 minutes later.

Network Security Tie-in: Micro-segmentation​

Because NHIs cannot use Multi-Factor Authentication (MFA), we must rely heavily on Network Security to limit their blast radius. This is where Micro-segmentation comes in.

If a human is compromised, we use ZTNA to block them. If a bot is compromised, we use micro-segmentation to trap it.

Think of micro-segmentation as building watertight bulkheads inside a submarine. If one section floods, the whole sub doesn't sink.

Visual Logic: Flat Networks vs. Zero Trust Micro-segmentation​

  • The Flat Network: Service Account Backup_Bot_01 has access to the central server VLAN. Because it is on that open VLAN, if it gets hacked, the attacker can pivot to ping the HR database, the engineering servers, and the customer web portal.
  • The Segmented Network: Backup_Bot_01 is placed in a micro-segment. The firewall rules state: This bot is ONLY allowed to communicate with IP Address 10.0.0.5 (The Backup Server) over Port 443. Any other traffic is immediately dropped.

Interactive Simulator: Micro-segmentation & Lateral Movement Simulator​

Draw connections and test how identity firewall rules act as the ultimate fail-safe:

Lateral Movement & Micro-segmentation Simulator

Configure network firewall rules for a compromised service account to test lateral containment.

Identity Firewall Rules

Configure permissions for the 'Backup Bot' service account:

To: Backup Storage
Port 443 (Authorized)
To: HR Records
Port 1433 (SQL)
To: Financial Ledger
Port 1433 (SQL)
🤖
Backup Bot
COMPROMISED
💾
Backup Storage
Required Dest.
🗄️
HR Records
No Access
💰
Financial Ledger
No Access

4. Control (Least Privilege and Rotation)​

The two guardrails for NHIs are incredibly strict:

  1. Least Privilege: Do not use Domain Admin for a bot that only needs to read one folder.
  2. Rotation: Passwords and API keys must be rotated automatically and frequently. If a key is stolen, it should be mathematically useless by the time the attacker tries to use it.

5. Impact (The Blast Radius)​

If a human intern's account is hacked, it's a bad day. If a root-level service account with a static password and no network segmentation is hacked, you will be on the front page of the Wall Street Journal. The impact of a compromised NHI is almost always classified as Critical.

Consultant's Corner: The Scream Test​

When dealing with thousands of undocumented legacy service accounts, no one will know what they actually do. If you ask the engineering team if you can delete one, they will say, "Don't touch it, it might break production."

The solution is the Scream Test.

You do not delete the account. Instead, you change its network password or block its port on the firewall. Then, you wait to see who screams that their application just stopped working. Once they scream, you have found the owner. You assign the owner to the identity, document the bot in the IAM system, and turn it back on. It is messy, but it is highly effective.