Inheriting NHIs in an Acquisition: Discovery and Triage

When you buy a company you inherit every service account, API key, OAuth grant and certificate it ever created, and most of them have no owner the deal team can name. Human accounts arrive with an HR record and a manager; non-human identities (NHIs) arrive as a pile of credentials whose creators may leave during the integration. This guide is a working method for the acquirer's identity and security team: where to look for inherited NHIs on each major platform, which signals tell you whether a credential is still used, how to score and triage what you find, and in what order to rotate, migrate or retire it. It assumes the deal has signed or closed. For the wider identity integration programme (coexistence, tenant consolidation, day one access), see the Identity Integration in M&A Guide; this page goes deeper on the non-human side only.

Source note: platform behaviour below is summarised from the AWS, Google Cloud, Microsoft and GitHub documentation listed in the references, as checked in November 2026. Phase timings and tiers are NHI Mgmt Group recommendations, not requirements. Confirm against the official text before relying on it.

Key takeaways

Assume the inventory you were given is incomplete. Due diligence lists come from people's memory and one directory; discovery has to read every identity plane the target runs, including test tenants and old cloud accounts.
Last-used data is the triage engine. AWS credential reports, Google Cloud service account insights, Entra service principal sign-in logs and similar signals separate live credentials from dead ones, but capture them early because log history is short.
Score on exposure, not just privilege. A low-privilege key known to the seller, a departing contractor or an outgoing managed service provider can matter more than an admin key held only in a vault.
"We think it is unused" is a reason to disable, not to skip. Disable first, watch for breakage, then delete, so a wrong guess costs an outage rather than a breach.
Every inherited NHI ends with a named owner and a dated decision. Keep, migrate, replace or retire, recorded in the acquirer's own inventory, with unowned identities disabled after a fixed hold period.

Why inherited NHIs behave differently

An acquisition breaks the three things that normally keep NHIs governed: the people who know them, the systems that record them and the logs that show their use.

Knowledge walks out: engineers who built integrations often leave in the first year after a deal, and the credentials they created were never in an HR feed. A service account's description field is frequently the only documentation.
Two sets of tools, neither complete: the target may use a different secrets manager, CI platform and identity provider. Your NHI discovery tooling does not yet see their estate, and theirs may not exist.
Hidden estates: test tenants, sandbox cloud accounts and proof-of-concept SaaS workspaces were outside the target's own controls. The Microsoft Midnight Blizzard breach started with a password spray against an account in a legacy non-production test tenant; the attacker then compromised a legacy test OAuth application that held elevated access to the corporate environment, according to Microsoft.
Credentials that cross the deal boundary: in a carve-out acquisition, some NHIs are still shared with the seller under a transitional service agreement, and others are known to the seller's staff. Those shared services need their own security terms and exit plan, covered in the Third-Party Access Guide.
Attackers watch deals too: announcements, staff turnover and helpdesk confusion make the integration period a good time to use a credential nobody is watching.

Discovery by phase

What you can do depends on the legal state of the deal. Before closing, the buyer usually cannot direct the target's operations or connect tooling to its systems, so agree with counsel what the target runs on your behalf and what it shares.

Phase	Access you normally have	NHI discovery actions
Due diligence (pre-signing)	Documents and interviews only	Ask for counts by type (service accounts, app registrations, cloud access keys, CI secrets, SaaS API keys, certificates), the secrets manager in use, the last credential rotation event and any known secret leaks. Missing answers are findings. See the Cyber Due Diligence in Mergers and Acquisitions Guide.
Signing to close	Target-run reports shared with the buyer	Ask the target to export credential reports, app registration lists and secret scanning results, and to preserve logs beyond default retention so history exists on day one.
Day one to day 30	Read-only audit roles in target platforms	Connect discovery tooling read-only; pull every identity plane listed below; snapshot permissions; start the last-used clock.
Day 30 to day 90	Delegated admin for agreed changes	Triage, assign owners, rotate high-exposure credentials, disable unused ones, begin migration to the acquirer's secrets manager and workload identity patterns.
Day 90 onwards	Integrated governance	Hold-period deletions, ownership attestation, migration of remaining NHIs, and inclusion in normal lifecycle controls.

Where to look: identity planes and last-used signals

Read each plane directly instead of trusting a combined spreadsheet. The method for building and reconciling a full inventory is in the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide; the table below lists what matters in an acquisition and the signal that tells you whether each credential is alive.

Plane	Objects to enumerate	Last-used or exposure signal	Watch out for
Active Directory	Service accounts, accounts with servicePrincipalName set, group Managed Service Accounts (gMSA), accounts with "password never expires"	lastLogonTimestamp, password last set	Shared passwords stored in scripts and scheduled tasks; accounts in privileged groups
Microsoft Entra ID	App registrations, service principals, enterprise apps, managed identities, credentials (secrets and certificates) on each	Service principal sign-ins and managed identity sign-ins in the sign-in logs; the Permissions blade (Admin consent and User consent tabs) for what each app can do	Multi-tenant apps consented in both tenants; app permissions such as mail access granted at tenant level
AWS	IAM users with access keys, IAM roles and trust policies, cross-account roles	IAM credential report columns access_key_1_last_used_date, access_key_1_last_rotated and password_last_used; IAM Access Analyzer unused access findings for unused roles, access keys and passwords	The credential report covers only the first two access keys per user and omits service-specific credentials, so also call ListAccessKeys and ListServiceSpecificCredentials
Google Cloud	Service accounts, user-managed service account keys, domain-wide delegation	Service account insights (accounts unused for 90 days); Key Authentication Events metric for when each key was last used	Insights and metrics are project-scoped, so iterate across every project, including orphaned ones
Source control and CI/CD	Fine-grained and classic personal access tokens, deploy keys, GitHub Apps and OAuth apps, CI variables and secrets, runner registration tokens	Organisation owners can list fine-grained PATs under Settings, Personal access tokens, Active tokens	Classic PATs are not visible to owners and reach organisation resources until they expire unless a PAT policy restricts them
SaaS platforms	API tokens, bot users, OAuth integrations, SCIM tokens, webhooks with shared secrets	Each platform's token admin page and audit log	Tokens created by individual admins who have left; integrations that reach the seller's tenant
Code and artefacts	Secrets committed to repositories, container images and build artefacts	Secret scanning results across full history	Secrets in history that were never rotated
PKI	TLS, code signing, SAML signing and client certificates, private CAs	Certificate inventory, Certificate Transparency logs for public domains	Private keys held by the seller or a former supplier

Two practical rules help. First, capture log-based signals in the first week and store them yourself, because sign-in and API logs have finite retention and you need a baseline before you start changing things. Second, record where every secret is stored, not just that it exists: a key in a vault with access logging is a different risk from the same key in a wiki page.

Triage: scoring what you find

A mid-sized target can have thousands of NHIs. Score each one on a small number of factors you can actually measure, then work the list in tiers. The general approach is covered in the NHI Risk Scoring Guide; these factors are tuned for an acquisition.

Factor	Higher risk when	Evidence
Privilege	Admin roles, tenant-wide application permissions, write access to production, domain-wide delegation	Role and permission snapshot
Exposure	Secret known to departing staff, the seller, an outgoing provider or found in code or tickets	Secret scanning, interviews, offboarding lists
Boundary crossing	Used by or shared with the seller or a third party	Trust policies, consent records, supplier lists
Credential type	Static secret or long-lived key rather than federation or managed identity	Credential metadata
Age and rotation	Never rotated or rotated more than a year ago	Last rotated fields
Activity	Used from unexpected networks or regions, or dormant then suddenly active	Last-used region and IP, sign-in logs
Ownership	No identifiable owner or owner leaving	Owner field, HR leaver list

NHI Mgmt Group recommends a tier scheme like this (adjust the windows to your risk appetite):

Tier 1, act within days: privileged or production NHIs that are exposed or cross the boundary. Rotate now, restrict source networks, alert on use.
Tier 2, act within 30 days: privileged NHIs that are not exposed, and exposed NHIs with low privilege. Assign an owner and schedule rotation or migration.
Tier 3, hold and disable: NHIs with no activity in the observation window. Disable, wait a fixed hold period, then delete.
Tier 4, migrate with the integration: owned, active, low-risk NHIs that will move to the acquirer's patterns in normal project order.

Disposition and rotation sequencing

Every NHI ends with one of four decisions, an owner and a date. Record them in your own inventory; the Service Account Inventory Template lists the fields.

Decision	Use when	What it involves
Keep	Active, owned, appropriately privileged, stays in the target environment	Rotate if exposed; enrol in acquirer monitoring and lifecycle
Migrate	Workload is moving to the acquirer's tenant, cloud or CI	New identity in the destination; old one disabled after cut-over
Replace	Static secret where federation, managed identity or workload identity federation is available	Re-engineer the integration; remove the static credential
Retire	No activity, no owner, or purpose ended	Disable, hold, delete; see the NHI Offboarding and Decommissioning Guide

Sequence rotations by who knows the secret, not by system:

Secrets known to people leaving at close: founders who are exiting, seller staff, contractors whose contracts end. Rotate these before or on their exit date.
Secrets held by outgoing providers: managed service providers, agencies and integrators the acquirer will not retain. Rotate when their access ends, and confirm in writing that they hold no copies.
Secrets found in code, tickets, chat or documents: treat as leaked. Rotate, then remove from history where possible. See the Developer Secret Scanning Triage guide.
Everything else in risk order, folded into migration so you rotate once rather than twice.

Disable before delete. Google Cloud's own guidance is to disable unused service account keys before deleting them so the change can be reversed, and the same pattern applies everywhere: disable, watch for errors over a hold period, then delete. The Cloudflare breach shows the cost of skipping this step the other way: after the October 2023 Okta incident, one service token and three service account credentials were left unrotated because they were believed to be unused, and an attacker used them from 14 November 2023.

Platform specifics worth knowing

Microsoft Entra ID: under Entra ID, Enterprise apps, All applications, each app's Permissions page has an Admin consent tab, where tenant-wide grants can be revoked, and a User consent tab, which cannot be revoked in the portal and needs Microsoft Graph or PowerShell. Revoking does not stop an app being consented again, so tighten user consent settings at the same time, and check Entra roles, Exchange RBAC and Teams resource-specific consent, which grant access outside the Permissions page.
AWS: generate the IAM credential report in every inherited account (it can be regenerated every four hours) and turn on IAM Access Analyzer unused access analysis across the organisation once the accounts join it. Review every role trust policy that names an account outside the new organisation. See the IAM Access Analyzer Guide.
Google Cloud: organisations created on or after 3 May 2024 enforce the Disable service account key creation and Disable service account key upload constraints by default; older target organisations may not. Apply them at the organisation root and set the Service Account Key Exposure Response policy to DISABLE_KEY.
GitHub: revoking a fine-grained PAT does not disable SSH keys that the token created, so review SSH and deploy keys separately. Set an organisation PAT policy that restricts classic PATs. For a leaked token, see How to revoke a leaked GitHub personal access token and check what it touched.

Decision guidance

Coexist or migrate early: if the target will run independently for a year or more, bring its NHIs under your monitoring and policy in place and migrate later. If its workloads are moving to your platforms within months, rotate only what is exposed now and let migration replace the rest, to avoid rotating twice.
Small target: a startup with one cloud account and one source control organisation can be fully enumerated in days. Rotate everything held by departing founders and contractors, then rebuild integrations under your standards.
Large or multi-acquisition target: expect several directories, test tenants and inherited acquisitions of its own. Start with privileged and boundary-crossing NHIs and accept that discovery will run for months.
Carve-out acquisition: when you buy a business unit from a larger seller, many NHIs are shared with the seller. Agree in the TSA which credentials the seller will rotate, by when, and how both sides prove it. The seller-side view is in the Identity separation in divestitures guide.
Unowned but active: do not delete. Find the consumer from logs (source IP, user agent, called APIs), assign a temporary owner from the integration team, and set a deadline for a permanent owner.

Detection and measurement

During integration, monitor inherited NHIs more closely than your own:

New credentials on existing identities: new secrets or certificates added to app registrations, new access keys on IAM users, new service account keys. This is ATT&CK T1098.001 Additional Cloud Credentials.
Use of dormant identities: any sign-in by an NHI marked Tier 3, and any use of a disabled credential.
New consents and app registrations in inherited tenants, especially tenant-wide application permissions.
Use from unexpected locations: last-used region in AWS, service principal sign-in IPs in Entra, compared with the baseline you captured in week one.

Metrics that show progress:

Percentage of inherited NHIs with a named owner and a recorded decision.
Percentage of Tier 1 NHIs rotated within the agreed window.
Count of static secrets replaced by federation or managed identity.
Count of NHIs disabled, and count re-enabled because the guess was wrong (a falling number shows better triage).
Number of planes and tenants discovered after day 30 (should trend to zero).

Common failure patterns

Treating the due diligence list as the inventory: it reflects what the target's team remembered. Discovery always finds more, typically in test environments and SaaS tools.
Skipping credentials "believed unused": the Cloudflare breach is the clearest example. Rotate or disable; never leave a credential live on a belief.
Ignoring the test tenant: legacy non-production environments with links into production, as in the Microsoft Midnight Blizzard breach.
Rotating after people leave: rotation scheduled for "after integration" rather than on each departing person's or provider's exit date.
Keeping unknown NHIs "until we understand them": without an owner and a date, understanding never arrives. Use the hold-and-disable tier.
Losing the baseline: waiting until tooling is connected to collect logs, by which time the history needed to judge activity has aged out.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	MITRE ATT&CK (threat addressed)
Inventory of inherited NHIs and services	ID.AM-02, ID.AM-04	CM-8 System Component Inventory	T1078.004 Cloud Accounts
Owner and disposition for each identity	PR.AA-01	AC-2 Account Management, IA-4 Identifier Management	T1078.004 Cloud Accounts
Rotation of exposed secrets	PR.AA-01	IA-5 Authenticator Management	T1552.001 Credentials In Files
Disable dormant NHIs	PR.AA-05	AC-2(3) Disable Accounts	T1078.004 Cloud Accounts
Review app consents and tokens	PR.AA-05	AC-2 Account Management	T1528 Steal Application Access Token, T1550.001 Application Access Token
Monitor new credentials and dormant use	DE.CM-03	AC-2 Account Management	T1098.001 Additional Cloud Credentials
Shared credentials with seller and providers	GV.SC-07, GV.SC-10	SA-9 External System Services	T1078.004 Cloud Accounts

The OWASP Non-Human Identities Top 10 (2025) risks most relevant to acquisitions are NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI8 Environment Isolation. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Practitioner checklist

Ask in due diligence for NHI counts by type, the secrets manager in use and the last rotation event, and record gaps as findings.
Before close, ask the target to extend log retention and export credential and app registration reports.
On day one, get read-only access to every identity plane, including test tenants, sandbox accounts and SaaS admin consoles.
Capture last-used baselines in week one: AWS credential reports, Entra service principal sign-ins, Google Cloud service account insights.
Score every NHI on privilege, exposure, boundary crossing, credential type, age, activity and ownership.
Rotate secrets known to departing staff, the seller and outgoing providers on their exit dates.
Disable unused NHIs, hold, then delete; never skip a credential because it is believed unused.
Give every NHI a named owner and a keep, migrate, replace or retire decision with a date in your own inventory.
Alert on new credentials added to inherited identities and on any use of a disabled or dormant NHI.
Report owner coverage and Tier 1 rotation progress to the integration steering group until both reach 100%.

Inheriting NHIs in an Acquisition: Discovery and Risk Triage