C · 04 / Cloud Security & Identity

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

AWS, Azure, and GCP each publish a shared-responsibility model that draws a hard line between what the provider secures and what you secure. Configuration, identity, data classification, and backup stay on your side of the line — and the default posture of a fresh tenant is not the posture of a hardened one. We run cloud posture management, SaaS hardening, SSO rollout, MFA and passkey migration, privileged access, conditional access, DLP, and real cloud backup. Documented, auditable, owner-named.

Cloud stacksAWS / Azure / GCP certified
SaaS specialtyM365 / Workspace CIS-aligned
IdP partnersOkta / Entra / Duo OneLogin · JumpCloud
PAM partnersCyberArk / Delinea HashiCorp Boundary
MFA posturePasskeys ready FIDO2 / WebAuthn
Assessment feeZero pre-engagement
42
Median CIS findings
Average open configuration gaps on a never-hardened Microsoft 365 tenant at first scan.
Shadow-IT expansion
Typical ratio of SaaS apps discovered versus apps the IT team knew about, across our last twenty CASB rollouts.
8 wk
Typical SSO cutover
Discovery-to-production timeline for a single identity provider and a catalog of twenty to forty SaaS apps.
93 d
Why you need backup
Maximum retention of a default M365 deleted-item recycle bin. It is not a backup, and carriers have stopped treating it like one.
01 / Cloud Stacks

Three clouds, one
discipline: least privilege,
continuous drift,
documented backup.

Every midsize organization we work with runs at least two of the three major clouds — typically Azure for identity and productivity, AWS or GCP for workloads, and a long tail of SaaS sitting on top. The failure mode is the same in all three: configuration drifts, IAM accretes, and nobody owns backup.

AWS
Amazon
Web Services

IAM policy review, SCP baselines, Config rules aligned to CIS AWS Foundations, GuardDuty tuning, S3 public-access block verification, KMS key rotation, and Backup vault configuration. Service-control-policy design for multi-account Organizations.

Azure
Microsoft
Azure + Entra

Azure Policy enforcement, Defender for Cloud regulatory compliance dashboards, RBAC scoping, Entra ID conditional access, Privileged Identity Management, Microsoft Sentinel integration, and Backup Vault configuration across subscriptions.

GCP
Google
Cloud Platform

IAM + organization policy review, Security Command Center Premium enablement, VPC Service Controls, Binary Authorization, Cloud DLP, Cloud KMS rotation, and organization-level backup-for-GKE plus workload-identity-federation for service accounts.

02 / Typical Gaps

Typical cloud gaps
we find — every
single assessment.

The list below is not theoretical. Every item here appears on more than eighty percent of the cloud posture assessments we deliver across TN and MS. If you have an untouched M365 tenant, a two-year-old AWS account, or a Google Workspace that grew with the company, count on seeing most of these.

01
Data exposure

Misconfigured S3, Blob, or GCS buckets

Public-read ACLs left on for a vendor test and never removed. Pre-signed URL patterns that outlive their usefulness. Buckets without default-encryption or object-lock. The 2019–2025 breach archive is built on this one finding.

02
IAM accretion

Permissive IAM roles and stale service principals

Roles granting *:* because somebody needed it once. Service principals for contractors who left in 2023. Access keys that have not rotated in eighteen months. Least privilege exists on the whiteboard, not in the console.

03
Break-glass

Legacy break-glass accounts with no rotation

The emergency admin account everyone forgot about — static password, no MFA, excluded from conditional access on purpose, last used in 2022. An attacker who finds it owns the tenant in ten minutes.

04
Backup reality

No real M365 or Workspace backup

Leadership believes the recycle bin is backup. It is not. Retention ranges from thirty to ninety-three days depending on the setting, and it does not protect against ransomware, mass purge, or departed-employee data aging out mid-discovery.

05
Service accounts

Unmonitored automation and service accounts

The backup agent, the CI/CD pipeline, the integration platform — each with static credentials, standing admin, and no alerting on abnormal use. Non-human identities outnumber humans four to one in most tenants we assess.

06
Visibility

Legacy authentication still enabled

Basic auth, SMTP AUTH, POP3 / IMAP — protocols that cannot honor MFA, still flipped on for a ten-year-old application nobody can identify. Conditional access cannot protect what legacy auth routes around.

07
Oversharing

External guest sprawl in SharePoint, Drive, and Teams

Anyone-with-the-link sharing on by default, guest accounts from three acquisitions ago, link re-sharing with no expiration. We routinely find thousands of documents addressed to external parties no one in the company recognizes.

08
Shadow IT

Unknown OAuth grants and sanctioned SaaS drift

Third-party apps with read-write access to Mail, Files, and Calendars — granted by end users without admin review. We find on average thirty-plus shadow OAuth consents in a never-audited M365 tenant, four to eight of which are high-risk.

03 / Methodology

Our cloud assessment
methodology.

Seven sequential stages. Every finding is mapped to a named benchmark — CIS AWS Foundations, CIS Microsoft 365, CIS Google Workspace, or the relevant NIST / HIPAA / PCI-DSS control — with an owner, a fix, and a verification step. No vague "tighten permissions" recommendations; each item gets the exact console path, CLI command, or policy document you need.

01

Inventory & scoping

Every cloud account, subscription, project, and SaaS tenant — discovered, confirmed, and scoped. Shadow-IT discovery via CASB log or OAuth-consent enumeration. Named contacts identified for each environment.

DeliverableScoping memo · NDADuration3–5 business days
02

Posture scan

CSPM tool of record — Wiz, Orca, Prisma, or an open-source stack of Cloud Custodian plus Steampipe plus ScoutSuite — configured against CIS Foundations, CIS M365, or CIS Workspace benchmarks, depending on environment. Raw finding pull, de-duplicated and owner-tagged.

DeliverableFinding registerDuration5–10 business days
03

Identity audit

Every human and non-human identity enumerated. Over-privileged roles flagged. Stale service principals, unused access keys, and standing admin accounts identified. Conditional access baseline reviewed against Microsoft and Okta reference designs.

DeliverableIdentity map · role treeDuration3–5 business days
04

SaaS hardening review

M365, Workspace, Salesforce, and top-tier business SaaS reviewed against CIS or vendor reference hardening. DLP policies, session controls, retention labels, conditional-access integration, and external-sharing posture audited end-to-end.

DeliverableSaaS posture reportDuration5–7 business days
05

Backup & recovery verification

Backup coverage mapped per data class. M365 and Workspace third-party backup configuration tested by restore. AWS Backup, Azure Backup Vault, and GCP Backup for GKE reviewed. Recovery-time objective vs. observed recovery time documented.

DeliverableBackup posture memoDuration2–4 business days
06

Remediation roadmap

Every finding — from the inventory, posture scan, identity audit, SaaS review, and backup verification — collapsed into a single prioritized thirty / sixty / ninety-day plan. Each item has an owner, a fix, an estimated hour-effort, and a verification method.

DeliverableRoadmap · owner-namedDuration3–5 business days
07

Executive brief

Signed PDF report, ten-slide executive deck, and a ninety-minute briefing to the sponsor and their invited stakeholders. Thirty-day follow-up Q&A window. Deliverable is portable: counsel-ready, carrier-ready, board-ready, and auditor-ready.

DeliverablePDF + deck + briefingDuration2–3 business days
04 / SaaS Hardening Playbook

Microsoft 365 and
Google Workspace —
specific lists.

We get asked for a checklist, so here is an abbreviated one. Every engagement runs the full CIS benchmark plus our own extended list — these are the items that move the needle fastest for a company that has never hardened the tenant.

Capability Enterprise Midmarket Open-source / startup
CSPM Wiz · Orca · Prisma Cloud Multi-cloud, agent-less Lacework · Qualys TotalCloud Guided baselines Cloud Custodian + Steampipe + ScoutSuite Owner-run
SSO / IdP Okta · Microsoft Entra ID App catalog at scale Duo SSO · OneLogin · JumpCloud MSP-friendly Keycloak · Authentik Self-hosted OIDC
PAM CyberArk · Delinea Full vaulting + session rec BeyondTrust · HashiCorp Boundary JIT + broker Teleport Community · Vault OSS Build-your-own
CASB / Shadow-IT Microsoft Defender for Cloud Apps · Netskope Deep OAuth + inline Zscaler ZIA · Cisco Umbrella DNS + inline NetBird · OpenZiti ZTNA overlay
DLP Microsoft Purview · Symantec DLP Cross-channel AWS Macie · Google Cloud DLP Cloud-native OpenDLP · Apache Ranger Data-store-specific
M365 / Workspace backup Veeam · Druva · Datto Immutable · granular Barracuda · Acronis MSP-packaged rclone + cold object store File-level only
MFA / Passkey YubiKey · Feitian + Entra / Okta Phishing-resistant Duo Push + Passkeys Population-friendly WebAuthn native platform Browser + OS only
05 / Project Types

IAM, PAM, and SSO —
named project shapes.

Identity projects tend to land in one of six shapes. Each has a typical timeline, a typical budget, and a typical point where it gets hard. We have run all six, more than once, across healthcare, financial, professional-services, manufacturing, and government-contractor environments.

P · 016–10 weeks

SSO rollout

Single identity provider — Okta, Entra ID, Duo SSO, OneLogin, or JumpCloud — with an app catalog of twenty to forty SaaS apps. Discovery, tenant configuration, SCIM provisioning design, pilot group cutover, wave-based migration, and legacy password retirement.

  • App catalog
  • SCIM
  • Pilot + waves
  • Help-desk playbook
P · 028–14 weeks

MFA & passkey migration

Population-wide phishing-resistant MFA. FIDO2 hardware keys for administrators and finance; synchronized passkeys via iCloud Keychain, Google Password Manager, and Windows Hello for the general population. Recovery and help-desk flow designed before rollout, not after.

  • FIDO2 + passkeys
  • Recovery flow
  • Fallback policy
  • Help-desk drill
P · 0310–16 weeks

PAM deployment

CyberArk, Delinea, BeyondTrust, or HashiCorp Boundary. Vaulting of the ten most-privileged credential sets, session recording on jump hosts, just-in-time elevation for cloud-native admin roles, and break-glass procedures for when the PAM itself is down.

  • Vault
  • Session rec
  • JIT elevation
  • Break-glass
P · 044–8 weeks

Conditional access overhaul

Entra ID conditional access or Okta adaptive authentication, built from a reference design and piloted in report-only mode. Device compliance, location, application, and sign-in risk weaved into a layered baseline that blocks legacy auth, steps up on risk, and restricts admin surface to managed devices.

  • Report-only pilot
  • Device compliance
  • Risk step-up
  • Exception register
P · 056–10 weeks

Shadow-IT + DLP program

CASB enablement — Defender for Cloud Apps, Netskope, or Zscaler ZIA — for sanctioned-app catalog, OAuth-consent governance, and inline risk policy. Purview, AWS Macie, or Google Cloud DLP policies tuned against labeled data. Integration with ticketing so findings actually close.

  • CASB baseline
  • OAuth governance
  • DLP rules
  • Ticketing integration
P · 063–6 weeks

Cloud backup deployment

Third-party backup for Microsoft 365 or Google Workspace via Veeam, Druva, or Datto. Retention defined per data class, restore drill before sign-off, RPO and RTO documented in writing. AWS Backup and Azure Backup Vault reviewed and tuned on the same engagement when the stack warrants it.

  • SaaS backup
  • Restore drill
  • RPO / RTO memo
  • Immutable copy
06 / Cloud FAQ

Questions we hear
every week.

If your question is not answered here, the senior engineer who would lead your engagement takes the call directly. Not a sales rep, not a gatekeeper. Dispatch will route you — or we will be on site within five business days for a walk-through before you commit to anything.

Is Microsoft 365 secure out of the box?

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.

Do I really need third-party backup for cloud data?

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.

What is PAM, and how is it different from IAM?

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.

How fast can we deploy SSO?

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.

Are passkeys ready for production rollout?

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.

What do people most often misunderstand about the shared responsibility model?

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.

How does AWS IAM differ from Azure RBAC?

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.

What is CSPM, and does a midsize company actually need it?

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.

What is shadow IT, and how do you find it?

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.

What is conditional access, and what should a first policy look like?

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.

How do you secure service accounts and non-human identities?

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.

What is a break-glass account, and do we really need one?

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.

07 / Next Step

Walk the tenant.
Write the plan.

Send us your clouds, your SaaS, and your identity provider. A senior engineer — the one who would lead your engagement — will be on the tenant within five business days. Pre-engagement posture walks are free; standalone cloud assessments are scope-priced and delivered on the timeline we commit to.