Machine-to-Machine Identity Is the Blind Spot in Enterprise Integration Security

Somewhere inside most large enterprises, a credential created during an integration project three years ago is still authenticating every few minutes, pushing production data into a finance system, listed under the name of a contractor who left in 2024.

It belongs to a machine. Through 2025 and into this year, attackers have concentrated on exactly these machine-to-machine identities across the integration layer that stitches ERP, CRM and plant systems together, because that layer tends to carry deep access and very little governance.

The numbers caught up with the pattern this spring. Verizon’s latest breach research put third-party involvement at 48% of all breaches, a 60% jump in twelve months and the second consecutive year of steep growth.

The same research recorded software vulnerability exploitation overtaking stolen credentials as the leading way in, which some have read as identity risk receding. That reading looks premature.

Both movements point at the same place, because the fastest route from an exploited edge device to anything worth stealing usually runs through whatever credentials that device holds.

Those are rarely vendor employees getting phished. They are connections. A token issued to an application, a service account provisioned during go-live, an API key pasted into a configuration file and forgotten by everyone including the person who pasted it.

Why a Decade of MFA Spending Never Reached This Layer

Multi-factor authentication, the control that absorbed a decade of security budget, does nothing here. A service account has no phone to prompt and no thumb to press. It presents a secret and it gets in.

The gap looks structural rather than accidental. Identity governance tooling was built around a human lifecycle where someone is hired, a manager approves access, someone resigns and the account closes.

Machine identities enter through a project plan and leave, if ever, through an outage.

Teams that have made real progress here generally stopped trying to force connectors into the human review cycle and built a parallel one instead, with its own cadence, its own owner list and its own working definition of what counts as dormant.

Where the Shop Floor Meets the Ledger

Manufacturing shows the shape of the problem more plainly than most sectors, because the integration is physical and the consequences turn up on a production line rather than in a quarterly report.

A plant that links its shop floor to its finance backbone through MES and ERP integration creates a credential that touches production schedules, work order costs and master data continuously, at machine speed, without ever surfacing in an access review.

Those connections also resist the usual remedies, because a factory measures itself in uptime.

Revoking a suspect credential on a corporate file share costs somebody an afternoon. Doing it to a live production link can stop a line, and the person authorised to make that call is rarely sitting in the security team.

Practitioners in these environments tend to solve it by settling the revocation decision in advance.

Writing down, before any incident, who can pull a specific integration credential and what production impact that carries turns a three-hour argument at 2am into a two-minute call.

What the Drift Campaign Proved About Trusted Connections

The Salesloft Drift campaign remains the reference case. Unit 42 documented a threat actor using compromised OAuth credentials between 8 and 18 August 2025 to pull data in bulk from Salesforce objects across customer environments, then combing what it stole for further credentials and deleting the query records behind it.

Nothing in Salesforce broke. The attacker used a legitimate integration doing roughly what it was built to do, at a volume nobody was watching.

The second-order damage is the instructive part. Support tickets and case notes are where engineers paste access keys during an outage, which had turned a CRM into a credential store nobody had classified as one.

That pattern shows up well beyond this incident. GitGuardian’s 2026 secrets research found roughly 28% of leak incidents originating entirely outside code repositories, in collaboration and ticketing tools, and rated those exposures critical 13 percentage points more often than secrets found in code alone.

Credentials reach those tools precisely because somebody needed fast access during an incident.

Detection tuned to anomalous human behaviour has no useful baseline for a connector that already queries tens of thousands of records on an ordinary Tuesday.

A workable starting point is to record the normal daily query volume and object mix for each major integration, then alert on deviation from that profile rather than on failed logins, which a valid token never generates.

The Integration Ships, the Ownership Never Arrives

The trouble starts earlier than the breach. Integration projects arrive with a budget, a deadline and a definition of done that reads “data flows between the two systems.” Nobody’s success metric says the access is bounded, attributed and revocable.

When OWASP published its first ranking of non-human identity risks, improper offboarding took the top position, ahead of secret leakage and excessive privilege.

The risk entry itself is blunt about why, rating prevalence as widespread and detectability as hard, and citing survey work in which roughly half of organisations reported no formal process to offboard or revoke long-lived API keys.

It also separates three failure modes worth distinguishing in practice, because stale credentials from a retired service, orphaned ones whose owner departed, and credentials a departing administrator merely had sight of each call for a different remedy.

That third case is the one most programmes miss. Rotating credentials a leaver could see, rather than only the ones formally assigned to them, is unglamorous work that almost never appears on an offboarding checklist.

Counting the Things You Cannot See

Ask a CISO how many non-human identities exist in the estate and the answer tends to arrive as a range.

Published ratios run from around 45 to 1 up to well past 80 to 1, depending on who ran the survey, which environments they sampled and what they agreed to count.

Treat that spread as a finding rather than noise. When credible research disagrees by a factor of two or three about how many identities are present, the likelier explanation is that most organisations cannot enumerate their own.

Survey data points the same way. The Cloud Security Alliance’s January 2026 study of non-human and AI identity security found only 12% of organisations highly confident in their ability to prevent attacks through non-human identities, with more than 16% not tracking the creation of new AI-related identities at all.

Part of the invisibility is architectural. These identities rarely live in the identity provider where governance tooling looks.

They live in Salesforce connected apps, in SAP communication users, in cloud IAM roles and in the admin console of whichever platform the integration touches, each carrying its own permission model and its own audit log.

Anyone starting from nothing tends to get further by ignoring the identity provider for a week and pulling the connected application list out of each major platform instead.

The count that comes back from the CRM, the ERP and the cloud tenant is usually well above what the architecture diagram implies, and the gap between those two figures makes a more honest risk metric than any maturity score.

A Rotation Clock That Stops at the Firewall

Certificates make the asymmetry concrete. The CA/Browser Forum voted in April 2025 to cut the maximum life of a public TLS certificate from 398 days to 47 in stages running from March 2026 to March 2029, with no votes cast against, choosing a period short enough that manual renewal stops being viable.

Read the scope carefully. Those requirements govern certificates for servers reachable over the public internet.

The certificates and secrets holding an internal ERP to MES connection together sit outside them.

So the public web is being pushed into automation by force, while machine credentials inside the plant can persist for years because no browser ever complains about them.

The forcing function stops at the firewall, and the credentials with the most operational reach are frequently the ones nobody is obliged to rotate.

The consequences are measurable. OWASP’s entry on long-lived secrets notes something close to an irony, rating these credentials easy to detect, since most secret managers display time since last rotation, yet widespread anyway, and it cites cloud research finding roughly 60% of keys older than a year.

When GitGuardian retested its own 2022 dataset four years on, 64% of those credentials were still valid.

Rotation gets avoided for reasons that are practical rather than lazy. Rotating an integration secret in production risks breaking a data flow with no rollback and no clear owner to call at 3am, so the secret stays, and five years later it is load-bearing infrastructure nobody dares touch.

The engineering answer is overlap. Systems that accept two valid credentials at once, the old and the new, allow a rotation to happen without a cutover, and integrations designed that way actually get rotated because rotation stops being a risk event.

Retrofitting that into an existing connector takes sprint time, though it generally costs less than the incident it prevents.

Persistence Is What Makes the Bill Large

OAuth integrations in Microsoft Entra ID can remain valid after the consenting user is disabled, and application access tokens bypass MFA by design rather than by flaw.

Reset every password in the organisation and the connector still works. That is what a connector is for.

Over-privilege compounds the exposure, and the reason is mundane. Scoping least privilege for an integration takes days of trial and error against a system that returns unhelpful errors, integration windows are short, and broad permissions make the pipeline succeed on the first attempt.

Read-write on everything ships on Friday. Read-only on four objects ships in March.

There is a way to get least privilege without paying that schedule cost. Teams that start a connector with no permissions and add them one at a time as calls fail arrive at a genuinely minimal scope in roughly the same elapsed time, because each failure names exactly what is missing.

The sequence, rather than any extra diligence, is what produces the tight scope.

Attackers walk the same privilege paths once inside, and a service account holding more rights than its function requires is often a shorter route to domain control than any human account on the network.

The Rules Have Started to Name This Problem

Regulation has moved slower than the threat, though it has begun to catch up in specific places. The payment card industry’s data security standard now treats application and system accounts as a category in their own right.

Requirement 8.6 covers how those accounts are managed, prohibits hard-coded passwords in scripts and configuration files, and calls for passwords to be changed periodically.

Those provisions moved from best practice to mandatory on 31 March 2025.

Teams well outside payments still find that framing useful, because it is one of the few widely audited standards to describe the problem in operational terms rather than in principle.

A security programme that could pass an 8.6 assessment across its whole integration estate would be ahead of most.

Agents Widen a Gap That Was Already Open

Agentic AI extends this failure mode rather than inventing one, which seems worth saying plainly while the marketing runs the other way.

Agents open their own connections and authenticate continuously, so the inventory problem grows without anyone raising a ticket.

The same CSA study found fewer than a quarter of organisations with documented, formally adopted policies for creating or removing AI identities. The governance gap existed well before the agents arrived.

What they mostly do is widen it faster than a quarterly review cycle can absorb.

Practical Moves for the Next Ninety Days

None of this requires new technology, which is probably why it stalls. Every integration credential needs a named human owner, a recorded expiry and a review that happens on a schedule rather than on recollection.

Ownership does the heaviest lifting of the three and gets skipped most often. An expiry date with no owner produces an outage and an emergency renewal that resets the clock for another year, which looks like control and functions as its opposite.

Name a person rather than a team, since distribution lists outlive the people on them.

Access reviews deserve particular attention. Human accounts get certified individually by managers who at least recognise the names, while service accounts arrive as a block at the end of the spreadsheet and get bulk-approved by whoever is closest to the deadline, producing an audit artefact and no security outcome.

An auditor who sampled ten service accounts and asked each nominal owner what the account does would find the gap in an afternoon.

Procurement is a quieter lever than most security teams realise. Third-party questionnaires ask at length about encryption at rest and certifications held, then never ask how many of your systems the supplier’s connector can read.

Adding that single question, and requiring the answer as a permission scope rather than a paragraph of prose, changes what vendors bring to the table.

Project closure is the last obvious gap. Integration credentials get created at kickoff and reviewed at nobody’s milestone, so attaching a credential inventory to the project sign-off document catches them while the engineers who built the thing are still available to explain what each one does.

The Question Worth Asking Tonight

Some of this may correct itself as identity vendors extend governance tooling to non-human accounts, and several are moving that way.

The trajectory still looks slower than the growth in machine identities, which suggests the gap widens before it closes.

Start with one system rather than the whole estate. Pull the connected application list from whichever platform holds the most valuable data, find an owner for every entry, and switch off what nobody claims.

That exercise usually takes about a week and tends to surface more than a year of policy work would.

Then ask for a list of every non-human credential that can read your ERP. And ask who in the building would notice if one of them started reading all of it.