Perimeter security is no longer enough
Google Cloud’s Cloud Threat Horizons H1 2026 report describes threats observed during the second half of 2025. Its most useful lesson for a small business is straightforward: access no longer comes only through a server or network to defend. It comes through a legitimate human or non-human identity that is already authorised to do something.
In the Mandiant engagements analysed by Google, identity issues were the initial access point in 83% of intrusions involving cloud and SaaS environments. Data was targeted in 73% of cloud-related incidents. These figures do not describe every company, but they point to a clear priority: knowing which identities can read, change or export data is now an operational requirement.
An identity is not always a person
A human identity is an employee, administrator or contractor account. A non-human identity may be a machine account, API key, OAuth token, SSH key or configuration used by a script.
For an attacker, the distinction matters less than the permissions obtained. A stolen SaaS token can open an integration without looking like an unusual login. An API key left in a file can enable automated actions. An over-privileged machine account can turn a small leak into persistent access to production.
The report also describes identity attacks using vishing, token theft and abuse of trust relationships between applications. A successful authentication therefore does not prove that the activity that follows is legitimate.
Software and identities amplify each other
The report observes a shift in access vectors: third-party software exploitation represented 44.5% of the initial access studied in the second half of 2025, compared with 27.2% for weak or absent credentials. The window from vulnerability disclosure to mass exploitation sometimes shrank from weeks to days.
That does not make credentials secondary. Compromised software is dangerous precisely because it runs in an environment where secrets are available. It can read a pipeline variable, a local configuration file, a token stored by a tool or an already-open session.
Dependency security and secret management must therefore be considered together: the fewer permanent secrets a workstation or pipeline contains, the less a software compromise can spread.
What a small business can do this week
You do not need a complex platform to start. A useful first review is to:
- Map access. List human accounts, machine accounts, API keys, SaaS tokens and configuration secrets that touch data or production.
- Reduce privileges. Remove unnecessary rights and separate administrative accounts from everyday accounts.
- Expire access. Prefer short, scoped tokens; revoke tokens whose owner, scope or expiry date is unknown.
- Monitor use. Look for unusual exports, high-volume API calls and new OAuth permissions.
- Verify sensitive requests. Confirm MFA changes, resets and new integrations through a second channel.
The goal is to answer three questions without searching through dozens of messages: who can access what, with which secret, and how do we know that access is still needed?
Which tool for which secret?
A local-first vault such as Soclyde is primarily for human secrets: SaaS passwords, shared access, recovery codes and administrative information. It limits copies in tickets, spreadsheets and conversations while keeping vault data under the team’s control.
Machine secrets need different safeguards: limited scope, expiry, rotation and logging. Secrets used by an application or pipeline should be injected by the platform’s secret manager and identity controls. Soclyde does not replace those controls; it helps keep human secrets and machine secrets from being mixed together.
The right model is therefore not “all local” or “all cloud”. It is explicit separation by use case, with as few privileges and copies as possible for each category.
To explore this separation, read Soclyde’s guide to local-first password managers.
