A secure cloud service still needs a secure company login

A business can buy a carefully operated cloud service and still leave its own account easy to enter. The useful purchasing question is whether the company has enforced its access rules, including exceptions for automated jobs. A feature labelled “MFA available” provides no assurance that the people holding your data must use it.

The 2024 Snowflake credential campaign makes that distinction concrete. It does not establish that every cloud incident starts at a customer login, or that one security control is always the best investment. It does give an owner a reason to examine access across the services the company already pays for.

What the investigation actually established

In its 10 June 2024 report, Mandiant attributed the incidents it investigated in this campaign to stolen customer credentials. It reported no evidence that those customer compromises originated in a breach of Snowflake's enterprise environment. That is a scoped investigation finding, not proof that the platform could never have a vulnerability.

Mandiant identified missing MFA, still-valid stolen credentials and missing network allowlists as contributing factors. Some credential exposure dated back to 2020. These details came from the later investigation; they should not be presented as facts already established when the story first broke in late May.

The Canadian Cyber Centre also recommended MFA and account hardening on 12 June 2024. Its alert is a mitigation recommendation, not an independent forensic conclusion about every affected account.

The business lesson is persistence. A stolen password can outlive the device infection that exposed it. Removing malware does not itself revoke a credential that has already been copied elsewhere. The response therefore needs to include the accounts reached from that device, rather than ending when the laptop appears clean.

Start with the data, then find the accounts

Begin an access inventory with services that hold customer records, financial documents or business secrets. Include exports and backups as well as the principal system. A reporting account may expose the same information as an administrator without having the same title.

For each service, record a named business owner, the person who can change access settings, human accounts and automated identities. Establish whether the organization controls the subscription and recovery address. A tool bought on an employee's personal account can become difficult to recover even without an attacker.

Then distinguish availability from enforcement. Ask for evidence that ordinary logins require the intended second factor and that exceptions are known. Someone should examine recovery methods and alternative login paths too. An enforced rule on the main sign-in page does little for an overlooked route that accepts only a password.

This is a proposed review method, not a claim that any particular vendor exposes all these settings in the same way. Product capabilities and subscription tiers differ. Where enforcement is unavailable, record the gap and decide whether the data should remain in that service.

Give automated access its own policy

A nightly import cannot respond to a human authentication prompt. Treating every service account as if it were an employee account produces either broken jobs or permanent exceptions nobody revisits.

Instead, ask what machine authentication the service supports. Prefer a separate identity for each integration, limited to the records and operations it requires. Where supported and appropriate, use short-lived credentials or workload identity. Otherwise, define how keys are stored, replaced and revoked. The important distinction is an explicit machine-access policy with a responsible owner.

Network restrictions can add another boundary when requests originate from predictable locations. They require planning for legitimate remote work and integrations whose addresses change. An allowlist does not establish that a request from an approved network is harmless. It reduces possible entry points; it does not replace identity checks.

The owner should be able to ask which automated identity can export the customer database and receive a specific answer. “The integration account” is too vague if several systems share it and nobody can safely revoke it.

Plan the inconvenient day

MFA introduces a recovery problem that needs a deliberate answer. A lost phone, unavailable employee or identity-provider outage can interrupt legitimate work. Define who can authorize recovery, how that person's identity is checked and how emergency access is recorded. Keep any emergency credentials under a separately reviewed procedure.

A practical acceptance exercise is to check an ordinary user's login, a recovery path and an integration's permissions in an agreed safe environment. Confirm that a disabled account actually loses access through the routes in use, including existing sessions where relevant. Agree these checks with the people responsible for the service before carrying them out.

Avoid turning the exercise into a password-age competition. A recent password used on an infected device can already be stolen; an older uncompromised secret is not automatically the most urgent issue. Look first for known exposure, excessive access and accounts that no longer have a legitimate owner.

The strongest objection is staff time

A small business may reasonably object that an organization-wide access review takes time away from selling and serving customers. Some SaaS tools also reserve central enforcement for more expensive plans. An indiscriminate programme can cost more than the immediate risk warrants.

Prioritize accordingly. Start with accounts that can move money, export sensitive records or change other people's access. Remove abandoned access before purchasing another security dashboard. Schedule remaining work against the information at risk, and make exceptions visible to the person accepting them.

MFA will not stop every attack. Session theft, deceptive approvals and compromised endpoints remain reasons to use several controls. The conclusion is narrower: where a reusable password is enough to reach valuable company data, closing that route is a concrete job with an observable result.

Treat access ownership as part of software maintenance. Require a current account inventory, documented exceptions and a recovery procedure someone can carry out. A vendor's security reputation cannot substitute for knowing who can enter your company's account today.