Your cloud is shared
responsibility. Most
aren't holding up
their side.

No. A default Microsoft 365 tenant ships with legacy authentication protocols available, no conditional access policies, minimal audit retention, basic DLP, and guest-sharing settings optimized for user convenience rather than protection. Every CIS-M365 benchmark scan we run on a never-touched tenant finds between forty and seventy configuration gaps — most of them medium to high severity.

Microsoft provides excellent primitives: conditional access, Defender for Cloud Apps, Purview, Entra ID Privileged Identity Management, Defender for Office 365. But they are pay-to-play features you must license, enable, and tune. Secure-by-default is not the same as secure out of the box, and no tenant we have ever audited came configured correctly on delivery.

Yes. Microsoft and Google are explicit about this in their shared-responsibility models. They are responsible for the resiliency of the infrastructure. They are not responsible for recovering your data after an accidental deletion, a ransomware event, a malicious admin, a departed-employee wipe, a misconfigured sync, or a compliance hold that arrives after the recycle bin has aged out.

The recycle bin is not a backup. Retention ranges from thirty days to ninety-three days depending on the service and the setting, and it offers no protection against a determined attacker or a mass-purge event. Real cloud backup runs through a third party — Veeam, Druva, Datto, Barracuda, Spanning, Acronis — with independent retention, granular point-in-time restore, immutable storage, and out-of-cloud-of-record copies. Every cyber carrier we work with has tightened backup language in the last eighteen months; several now decline coverage for M365-resident data without a named third-party backup on file.

Identity and access management (IAM) is the broader discipline of who every user is and what they are allowed to do across every system: provisioning, deprovisioning, group membership, role assignment, everyday authentication. IAM is horizontal — it covers everyone.

Privileged access management (PAM) is a narrower, deeper discipline focused specifically on accounts that can cause damage: domain administrators, cloud root accounts, cloud service principals, database administrators, network-device credentials, application-service accounts, break-glass accounts. PAM adds vaulting so credentials are checked out for a specific task rather than handed out permanently, session recording so every privileged action is captured on video and keystroke, just-in-time elevation so nobody is a standing administrator, and break-glass procedures for the account that nobody uses until everything else has failed. Most organizations have IAM and believe they have PAM because they have long admin passwords and an ImportantAdmins group. They do not.

For a single identity provider and a catalog of twenty to forty SaaS applications, six to ten weeks end-to-end is realistic: discovery, tenant configuration, SCIM provisioning design, pilot-group cutover, wave-based migration of the remaining population, and retirement of legacy password flows. The technical deployment is rarely the long pole.

The long pole is app-owner wrangling. Every SaaS app has to be converted from local passwords to SAML 2.0 or OIDC, and a handful will resist on licensing — "you need the Enterprise tier for SSO" — or on capability grounds. We front-load that conversation in discovery so the surprises surface in week one rather than week six. Larger migrations — fifty to a hundred apps, multiple IdPs consolidating, or identity-governance on the same work stream — scale out to four to six months.

Yes. As of 2026, FIDO2 and WebAuthn passkeys are supported natively by Apple, Google, and Microsoft platforms, with synchronized passkeys across iCloud Keychain, Google Password Manager, and Windows Hello. Device-bound passkeys on FIDO2 security keys provide the highest assurance for admin-tier accounts.

Enterprise identity providers — Okta, Microsoft Entra ID, Duo, OneLogin, JumpCloud — all support passkeys as a phishing-resistant MFA factor, typically alongside hardware keys for privileged roles. The practical question is not whether the technology is ready, but whether your help desk has a tested recovery process for a lost device, a stolen phone, or a departed employee. Answer that and you can deploy passkeys organization-wide. We do not recommend passkey-only rollouts without FIDO2 hardware fallback for admins — you need the unsynchronized factor for the day the synchronization service itself is compromised.

Two things. First, organizations assume the cloud provider's responsibility grows as they move up the stack — IaaS to PaaS to SaaS — when in reality the provider's responsibility only shrinks in SaaS for infrastructure, while leaving customer configuration, data classification, identity, and backup entirely on the customer. A SaaS app does not mean a safer data posture; it means a different one.

Second, organizations treat shared responsibility as a contractual abstraction rather than an operational reality. On the day a misconfigured S3 bucket leaks client data, the carrier and the regulator are not interested in who owned the physical disk. AWS is responsible for the cloud. You are responsible for what is in it, who accesses it, and how it is backed up. Every post-incident review we run on a cloud breach lands on a shared-responsibility failure — on the customer side.

AWS IAM is policy-centric. Identities, groups, and roles are attached to JSON policy documents that explicitly grant or deny specific actions on specific resources with optional conditions. This gives very fine-grained control at the cost of a lot of policy documents to maintain — and a real risk of inadvertent over-grant via Resource: "*".

Azure RBAC is role-centric. Built-in and custom roles define a set of permissions, and role assignments bind those roles to a principal (user, group, service principal, managed identity) at a scope (management group, subscription, resource group, resource). You get cleaner role reuse and easier scope management, at the cost of role sprawl if custom roles proliferate without governance.

GCP splits the difference with IAM roles plus fine-grained conditions and organization policy. All three clouds reward the same practices: least-privilege baseline, quarterly access review, aggressive cleanup of unused service accounts and access keys, and no standing admin. The tooling differs; the discipline does not.

Cloud security posture management (CSPM) is continuous inventory, configuration scanning, and drift detection across cloud accounts. A CSPM tool tracks every resource against CIS benchmarks, PCI-DSS, HIPAA, SOC 2, or custom baselines, and surfaces drift as it happens rather than as an incident. It is the difference between knowing what your cloud looked like in March and knowing what it looks like right now.

A midsize company with even a single AWS account, an Azure tenant, or a GCP project benefits because cloud configuration changes constantly. A developer opens a port for a demo, a new IAM role is granted for a migration, a storage bucket is made public for a vendor test, a service quota is raised — and manual quarterly review cannot keep up. Tools range from enterprise suites like Wiz, Orca, and Prisma Cloud to open-source stacks like Cloud Custodian plus Steampipe plus ScoutSuite. We help pick the right one for your stack and budget, then wire it into your ticketing system so findings actually get fixed.

Shadow IT is every SaaS application employees signed up for without telling IT — the free-tier project tool, the marketing survey service, the AI writing assistant, the invoice-scraper plugin, the third-party add-on connected to OneDrive. In a healthy midsize company we routinely find between three and eight times as many cloud apps in active use as the IT team knew about.

Discovery runs through a cloud access security broker (CASB): Microsoft Defender for Cloud Apps, Netskope, Zscaler ZIA, or Cisco Umbrella. These platforms inspect outbound traffic or OAuth consent grants to enumerate every cloud service employees actually reach. The findings then drive a three-bucket decision — sanction, restrict, or block — with priority given to apps that received OAuth grants into Microsoft 365 or Google Workspace without admin approval. High-risk consent grants get revoked first; sanctioned apps get moved behind SSO; everything else gets a policy.

Conditional access is a policy engine — implemented natively in Microsoft Entra ID and Okta adaptive authentication — that decides whether to allow a sign-in based on the combination of user, device, location, application, and a real-time risk score. Instead of a single password+MFA gate at the door, conditional access makes the gate smart.

A sensible starting policy set, in plain language: block legacy authentication entirely; require MFA for every external sign-in; require a compliant or hybrid-joined device for privileged roles and finance applications; block sign-ins from countries you do not operate in; step up to phishing-resistant MFA for anyone flagged as high risk. The trap is deploying broad policies without report-only piloting — you will lock out a CFO on a Saturday, and you will hear about it. We pilot every new policy in report-only mode for two weeks before enabling it, and we keep a named exception register reviewed monthly.

Service accounts and automation identities are the underexamined half of IAM. Human accounts get password rotation, MFA, conditional access, and quarterly review. Non-human accounts get a long static password and a prayer.

The fix is a short, unforgiving list. Inventory every non-human identity across AWS, Azure, GCP, Microsoft 365, and Google Workspace. Assign an owner to each — a named person who is accountable, not a distribution list. Rotate credentials on a defined schedule, or better, eliminate static credentials entirely in favor of AWS IAM Roles Anywhere, Azure managed identities, GCP workload identity federation, or OIDC-based CI/CD. Enforce least privilege with quarterly review. Alert on use outside expected patterns — a service account that normally runs at 2 a.m. authenticating at 3 p.m. from a new IP is worth investigating.

For the highest-risk automation — build systems, deployment pipelines, backup agents — we route credentials through a PAM vault with just-in-time checkout and full session logging, the same way human privileged accounts are handled.

A break-glass account is an intentionally unused, heavily protected administrator account that exists specifically for the day conditional access, MFA, SSO, or the identity provider itself is broken — and somebody still has to get in to fix the problem. Without it, a misconfigured conditional access policy or a federated-IdP outage can lock the entire tenant out, sometimes for days.

The pattern is unambiguous: two dedicated cloud-only accounts, excluded from conditional access by design, protected with hardware FIDO2 keys stored in a physical safe with access split between two officers, rotating passwords in a sealed envelope, alerting configured on every authentication attempt, and a quarterly drill to verify the keys still work. Every organization running Microsoft 365 or Microsoft Entra ID needs these — Microsoft itself published the pattern — and most organizations we audit do not have them configured correctly. We verify break-glass configuration on every cloud posture assessment, and fixing it is often the single highest-leverage change we recommend in the ninety-day plan.