App-to-App Access and Integrations

Access reviews look at people. A large and growing share of access belongs to software, and almost nobody reviews it.

What exists in this layer

OAuth grants from one platform to another, authorised by a user or an administrator.

API keys and tokens issued by one application and stored in another.

Service accounts created for an integration.

Webhooks pushing data outward on events.

Marketplace applications installed into a platform.

Automation platforms that hold credentials for dozens of systems and move data between them on rules nobody has reviewed.

That last category is the one to look at first. A single automation account frequently has broader access than any human in the organisation.

Why it is riskier than user access

No offboarding. Software does not leave, so nothing triggers a review.

Broad scopes. Integrations are commonly granted more access than they need, because narrowing takes effort and the broad option works immediately.

No attribution. Actions appear as the service account, so an audit log shows what happened and not who caused it.

Credentials stored in another system, whose security you may not have assessed.

Silent continuation. An integration for a project that ended three years ago keeps running and keeps holding access.

Compounding. Application A can reach B, which can reach C. The effective access of a compromise of A is not obvious from A's permissions alone.

Inventorying it

Per major platform, list connected applications and integrations.

Record: source, destination, what data moves, direction, credential type, who authorised it, when, and why.

Map the graph. Which systems can reach which. For most organisations this has never been drawn and drawing it is informative on its own.

Identify the concentrators: automation platforms, integration middleware, data pipelines. These hold the most access and deserve the most scrutiny.

Reducing the exposure

Least privilege at the scope level. Most integrations request broad scopes and function with narrow ones. Reducing requires reading the documentation and testing, which is why it rarely happens.

Dedicated service accounts, not a person's credentials. An integration running as a departed employee's account is both a security problem and an outage waiting for their offboarding.

Credential rotation on a schedule, which requires knowing where each credential is stored.

Expiry where the platform supports it.

Approval for new integrations, at least for those requesting write or administrative scopes.

Reviewing it

Quarterly for high-scope integrations.

Annually for the rest.

The questions: is this still needed, is the scope still minimal, is the owner still here, has the credential been rotated, is the data flow still what we recorded.

Include it in the application register rather than tracking it separately, so an application's entry shows what it can reach and what can reach it.

The incident question

When an application is compromised, what else is exposed?

Answering that requires the integration map. Organisations without one spend the first day of an incident working out what the affected system could reach, which is the worst possible time to be drawing the diagram.

Build it before you need it. It is a half-day exercise for most estates and it is the artefact incident response asks for first.

Drawing the integration map

A half-day exercise that produces the artefact incident response asks for first.

One node per system, limited to the ones holding meaningful data.

One edge per integration, with an arrow for direction of data flow.

Label each edge with what moves and the credential type.

Mark the concentrators — automation platforms and middleware holding many credentials.

Mark the boundary crossings: anywhere data leaves a higher classification for a lower one.

Keep it to one page. A complete map nobody can read is less useful than a partial one covering the systems that matter.

Review it after any significant integration change, and keep a copy with the offline register.

Rotating credentials you cannot find

Credential rotation is standard advice and it fails on the step nobody plans: locating where each one is stored.

Inventory storage locations first: automation platforms, CI systems, application configuration, developer machines, documentation, and password managers.

Record the location in the integration register at creation, which is the only reliable moment.

Prefer platform-managed credentials where available, since they rotate without anyone finding anything.

Prefer short-lived tokens over long-lived keys.

Where a long-lived key is unavoidable, set a rotation date and treat a missed one as a finding.

A credential nobody can locate cannot be rotated and cannot be revoked cleanly in an incident, which is the actual reason this matters.