Identity & Access

Why MFA Alone Isn’t Enough Anymore

Multi-factor authentication is, without question, one of the highest-impact security controls a business can implement. Microsoft has reported that MFA blocks the overwhelming majority of automated, credential-based attacks. But “blocks most attacks” is not the same as “makes you safe” — and treating MFA as a finish line rather than a starting point is one of the most common identity mistakes we see.

Where MFA Falls Short

MFA fatigue attacks. Attackers who already have a valid password can simply bombard a user with repeated push notifications until, out of annoyance or confusion, the user approves one. This doesn’t require breaking encryption or guessing a code — it relies on human fatigue.

SIM swapping. SMS-based MFA can be defeated if an attacker convinces a mobile carrier to transfer a victim’s phone number to a new SIM card, intercepting one-time codes.

Session token theft. Modern attacks increasingly target the authenticated session itself — stealing a browser cookie or token after MFA has already succeeded, bypassing the need to defeat MFA at all.

Legacy authentication protocols. Older protocols (like legacy SMTP or POP/IMAP) sometimes don’t support modern MFA challenges at all, creating a silent bypass path if they’re not explicitly blocked.

What to Add Alongside MFA

Number matching / phishing-resistant MFA — Use authentication methods that require the user to enter a code shown on the login screen (rather than a simple approve/deny tap), which defeats fatigue attacks. Where possible, move toward phishing-resistant methods like FIDO2 security keys or certificate-based authentication for high-privilege accounts.
Conditional Access policies — Require MFA based on risk signals (unfamiliar location, unfamiliar device, impossible travel) rather than treating every login the same way.
Block legacy authentication entirely — Legacy protocols that can’t support modern MFA should be disabled organization-wide unless there’s a specific, documented business need.
Session and token protection — Enable continuous access evaluation and shorten token lifetimes for sensitive applications, so a stolen session token has a much smaller window of usefulness.
Privileged account hardening — Admin and privileged accounts should use stronger authentication methods than standard users, and ideally shouldn’t have standing access at all (see Just-in-Time Access).

Why This Matters

Identity has become the primary battleground in modern attacks — not because MFA doesn’t work, but because attackers have adapted around the most common implementations of it. The goal isn’t more security theater; it’s closing the specific gaps attackers are actually using today.

How We Help

An Identity & Access Risk Review looks specifically at how MFA is enforced across your environment — including the gaps most audits miss, like legacy protocols, guest accounts, and privileged account exceptions.

Azure Security Misconfigurations We See Most Often

Most cloud breaches don’t start with a sophisticated exploit. They start with something far simpler: a setting left wrong. Gartner has estimated for years that the vast majority of cloud security failures are the customer’s fault, not the cloud provider’s — and Azure is no exception. Below are the ten misconfigurations we run into most often when auditing Azure environments, along with what to check and how to fix each one.

1. Storage Accounts With Public Blob Access Enabled

Azure Storage accounts can be configured to allow anonymous public read access to blob containers. This is sometimes turned on intentionally for a specific use case — and then never turned off, exposing every file in that container to anyone with the URL.

Fix: Go to your Storage Account → Configuration → set “Allow Blob public access” to Disabled unless you have a specific, documented reason otherwise.

2. Overly Permissive Network Security Groups (NSGs)

We frequently find NSG rules allowing inbound traffic from “Any” source on sensitive ports like RDP (3389) or SSH (22). This means literally anyone on the internet can attempt to connect.

Fix: Restrict inbound rules to specific IP ranges (your office, VPN, or a bastion host), and use Azure Bastion instead of exposing RDP/SSH directly.

3. Disabled or Partial MFA Enforcement

It’s common to find MFA enforced for regular users but not for service accounts, break-glass accounts, or guest users — exactly the accounts attackers target because they’re often overlooked.

Fix: Use Conditional Access policies to enforce MFA across all account types, with a documented, monitored exception process for true emergency accounts only.

4. Excessive Owner/Contributor Role Assignments

We regularly see far more users assigned “Owner” or “Contributor” at the subscription level than actually need that access — often because it was the easiest option at the time, not the correct one.

Fix: Apply least-privilege role assignments at the resource group or resource level instead of the subscription level, and review role assignments quarterly.

5. Missing or Disabled Diagnostic Logging

Without proper logging enabled on key resources (storage accounts, key vaults, network security groups), you have no way to detect or investigate suspicious activity after the fact.

Fix: Enable Diagnostic Settings on critical resources and route logs to a Log Analytics workspace or SIEM for retention and alerting.

6. Key Vault Access Policies That Are Too Broad

Azure Key Vault holds your secrets, certificates, and encryption keys — but we often find access policies granting broad permissions to service principals or users that don’t need them.

Fix: Use Key Vault’s RBAC model instead of legacy access policies where possible, and grant the minimum permission set (e.g., “get” secrets, not “list, get, set, delete”).

7. Unrestricted Management Ports on Virtual Machines

Similar to the NSG issue above, but specific to individual VM network interfaces — management ports left open directly on a VM, bypassing broader network controls.

Fix: Audit VM-level NIC rules separately from subnet-level NSGs; both need to be checked, since either one being open can expose the VM.

8. No Resource Locks on Critical Infrastructure

It’s surprisingly common for critical resources (production databases, key vaults, core networking) to have no lock preventing accidental deletion or modification.

Fix: Apply “CanNotDelete” or “ReadOnly” locks on critical resources through Azure Resource Manager.

9. Guest Users With Unreviewed, Lingering Access

Azure AD B2B guest access is convenient for collaboration, but guest accounts from old projects or former partners often stay active long after they’re needed.

Fix: Set up Azure AD Access Reviews to periodically re-certify guest and external user access, with automatic removal if not approved.

10. Default Encryption Settings Left Unverified

Azure encrypts data at rest by default in most services, which can create a false sense that “encryption is handled.” But encryption key management (customer-managed vs. platform-managed keys), encryption in transit enforcement, and specific service configurations still need to be verified.

Fix: Confirm “Secure transfer required” is enabled on storage accounts, and evaluate whether customer-managed keys are appropriate for your compliance requirements.

Why This Matters

None of these misconfigurations require an advanced attacker to exploit — most can be found with automated scanning tools within minutes. The risk isn’t sophistication; it’s visibility. Most organizations don’t have a full, current picture of their Azure environment’s configuration until something goes wrong.

How We Help

A Cloud Security Assessment gives you a complete, prioritized view of exactly these kinds of issues — not a generic checklist, but findings specific to your environment, ranked by real risk, with a clear remediation plan.

Vulnerability Management

Most vulnerability management programs still lead with CVSS (Common Vulnerability Scoring System) severity as the primary sorting criteria: fix all the “Critical” and “High” findings first, work down from there. It sounds logical. In practice, it often means teams spend weeks patching vulnerabilities that were never realistically exploitable, while genuinely dangerous issues sit lower on the list, unaddressed.

The Problem With CVSS-Only Prioritization

CVSS measures theoretical severity — how bad a vulnerability could be in a worst-case scenario. It does not account for:

Whether the vulnerability is actually reachable in your specific environment (internet-facing vs. isolated internal system)
Whether working exploit code exists and is actively being used by attackers
What compensating controls you already have in place (network segmentation, WAF rules, endpoint detection)
What the vulnerable asset actually does — a critical vulnerability on a decommissioned test server is a very different risk than a moderate one on your customer database

The result: two organizations can have identical CVSS-based vulnerability lists and completely different real-world risk exposure.

A Better Framework: Risk-Based Prioritization

Exploitability, not just severity. Cross-reference vulnerabilities against known exploited vulnerability catalogs (like CISA’s KEV list) and threat intelligence on active exploitation — a “Medium” severity bug being actively exploited in the wild deserves faster action than a “Critical” one with no known exploit.
Exposure. Is the vulnerable system internet-facing, or isolated on an internal segment behind multiple controls? Exposure changes real risk dramatically, even for the identical vulnerability.
Asset criticality. Tie vulnerabilities to what the affected system actually does for the business. A vulnerability on a system holding customer data or processing payments should outrank the same vulnerability on a low-value internal tool.
Chaining potential. Some “low” severity issues become serious when combined — for example, an information disclosure bug that reveals internal usernames, paired with a weak authentication flow. Point-in-time scanning often misses these combinations.
Remediation cost vs. risk reduction. Sometimes a compensating control (like a firewall rule) reduces risk faster and cheaper than a full patch cycle, especially for legacy systems where patching is complex.

Building a Realistic SLA

Rather than “patch all Criticals in 15 days” across the board, a risk-based SLA might look like:

Actively exploited + internet-facing → 48–72 hours
High severity + internet-facing, no known exploit → 7–14 days
High severity + internal only → 30 days
Everything else → next regular patch cycle, reviewed quarterly

Why This Matters

Vulnerability backlogs are rarely a resourcing problem alone — they’re often a prioritization problem. Teams burn capacity on low-impact fixes while real risk goes unaddressed, not because they’re careless, but because CVSS alone doesn’t tell the full story.

How We Help

Vulnerability Prioritization takes your existing scan data and re-ranks it using exploitability, exposure, and business context — so your team spends its limited time on the fixes that actually reduce risk.

Security Architecture

Zero Trust Architecture Explained

“Zero Trust” has become one of the most overused terms in security marketing, to the point where many teams are unsure what it actually means beyond a buzzword. Stripped of the marketing, Zero Trust is an architectural philosophy, not a product — and understanding the underlying principles matters more than any specific tool you buy to implement it.

The Core Idea

Traditional network security assumed that anything inside the corporate network perimeter could be trusted, and anything outside it could not. Zero Trust rejects that assumption entirely: no user, device, or system is trusted by default, regardless of whether it’s inside or outside the network. Every access request is verified, every time, based on multiple signals.

Three Core Principles

1. Verify explicitly. Every access decision should be based on all available signals — user identity, device health, location, and behavior patterns — rather than network location alone. Being “on the corporate VPN” should not automatically grant trust.

2. Use least-privilege access. Users and systems should have access only to what they specifically need, for only as long as they need it — not broad, standing access “just in case.”

3. Assume breach. Design your architecture as if an attacker is already inside your network. This means segmenting systems so a compromise in one area doesn’t automatically grant access everywhere else, and maintaining strong logging so you can detect and contain an intrusion quickly.

What Zero Trust Looks Like in Practice

Identity-centric access control — Strong authentication (including phishing-resistant MFA) becomes the primary gatekeeper, not network location.
Micro-segmentation — Breaking flat networks into smaller zones, so lateral movement after a breach is much harder.
Device health checks — Verifying a device meets security requirements (patched, encrypted, managed) before granting access, not just verifying the user.
Continuous monitoring — Access isn’t a one-time gate at login; sessions are continuously evaluated for risk signals.

Common Myths

“Zero Trust means buying a specific product.” No single product implements Zero Trust — it’s achieved through a combination of identity, network, and endpoint controls working together, often using tools you may already own but haven’t fully configured.

“Zero Trust is all-or-nothing.” In reality, Zero Trust adoption is incremental. Most organizations start with identity (strong MFA, conditional access) and expand into network segmentation and device trust over time.

“Zero Trust replaces perimeter security.” It doesn’t eliminate the need for firewalls or network controls — it adds identity and context as additional, often more important, layers on top.

A Realistic Starting Roadmap

Strengthen identity: phishing-resistant MFA, conditional access policies
Inventory and classify assets: know what you have and how sensitive each system is
Segment critical systems: isolate your most sensitive data and systems from general network traffic
Add device health requirements for access to sensitive resources
Build out continuous monitoring and logging to support the “assume breach” principle

Why This Matters

Perimeter-only security fails the moment an attacker gets a single set of valid credentials — which happens constantly, through phishing, credential stuffing, or third-party breaches. Zero Trust architecture limits how far that single compromise can spread.

How We Help

Security Architecture Consulting reviews your current design against Zero Trust principles and builds a realistic, prioritized roadmap — starting with the highest-impact, lowest-disruption changes first.

[Button: Book a Free Consultation]

Compliance

What to Fix Before the Auditor Arrives

SOC 2 has become a de facto requirement for many B2B companies, particularly SaaS businesses selling to enterprise customers. But going into a SOC 2 audit unprepared is expensive, stressful, and often results in exceptions or a delayed report. A readiness assessment before the real audit consistently surfaces the same handful of gaps — here’s what to check first.

1. Know Which Trust Service Criteria Actually Apply

SOC 2 covers five Trust Service Criteria: Security (mandatory for every SOC 2 report), Availability, Processing Integrity, Confidentiality, and Privacy. Many companies default to including all five without evaluating whether they’re actually relevant — adding unnecessary scope, cost, and audit time. Start by confirming which criteria genuinely apply to your business and customer commitments.

2. Documented Policies, Not Just Practices

Auditors need to see written policies — not just confirm that good practices exist informally. Common gaps include missing or outdated: Information Security Policy, Access Control Policy, Incident Response Plan, Change Management Policy, and Vendor Management Policy.

3. Access Control Evidence

This is one of the most common failure points. You need to demonstrate:

Formal onboarding and offboarding processes (with evidence — tickets, approvals)
Periodic access reviews (quarterly is typical), with documented sign-off
MFA enforcement across systems in scope

4. Change Management Evidence

Auditors expect to see evidence that code and infrastructure changes go through a consistent, approved process — pull request approvals, deployment logs, and a documented rollback process.

5. Vendor and Third-Party Risk Management

If you rely on subprocessors (cloud providers, SaaS tools handling customer data), you need a documented process for evaluating their security posture before onboarding, and periodically afterward.

6. Logging and Monitoring

You need to show that security-relevant events are logged, retained for an appropriate period, and actively monitored — not just collected and ignored.

7. Incident Response Readiness

Beyond having a written plan, auditors often look for evidence the plan has actually been tested — a tabletop exercise or documented incident walkthrough within the audit period.

8. Employee Security Awareness

Documented onboarding security training and periodic refreshers, with completion tracking, are typically expected.

A Simplified Pre-Audit Checklist

Confirmed which Trust Service Criteria are in scope
All core policies written, approved, and dated within the last 12 months
Access review process documented and evidence collected for the audit period
Change management process documented with evidence
Vendor risk assessment process documented
Logging/monitoring evidence available for the audit period
Incident response plan tested at least once in the audit period
Security awareness training completion tracked

Why This Matters

Most SOC 2 exceptions aren’t caused by weak security — they’re caused by weak evidence. Good practices that were never documented or consistently followed are treated the same as practices that don’t exist at all, from an auditor’s perspective.

How We Help

A Compliance Readiness Assessment walks through exactly these areas ahead of your real audit, so gaps get fixed on your timeline — not discovered by the auditor on theirs.

[Button: Book a Free Consultation]

AI in Security (Thought Leadership)

AI in Cybersecurity Operations: Where It Actually Helps Today

AI in cybersecurity is surrounded by two extremes: vendors promising it will replace entire security teams, and skeptics dismissing it as marketing noise. The reality, as usual, sits in between — AI provides real, measurable value in specific parts of security operations, while other parts still fundamentally require human judgment.

Where AI Genuinely Helps

Alert triage and noise reduction. Security teams are often flooded with far more alerts than they can manually review. AI-assisted triage can cluster related alerts, suppress known false-positive patterns, and surface the handful that genuinely need human attention — turning an unmanageable queue into a workable one.

Anomaly detection at scale. Identifying unusual patterns across massive volumes of log data — a login from an unusual location, an atypical data transfer volume, an account behaving differently than its historical baseline — is a task well-suited to machine learning, since it involves pattern recognition across scale that would be impractical to do manually.

Vulnerability and risk prioritization. As covered in our vulnerability prioritization article, AI-assisted analysis can help correlate exploitability data, threat intelligence, and asset context far faster than manual review, surfacing genuinely urgent issues sooner.

Phishing and social engineering detection. Modern email security tools use AI to detect subtle indicators of phishing beyond simple keyword or blocklist matching — analyzing writing style, sender behavior patterns, and link characteristics together.

Accelerating investigation. During an incident, AI-assisted tools can quickly summarize related events, pull relevant context, and suggest next investigative steps — reducing the time analysts spend on manual data gathering.

Where Human Judgment Still Matters Most

Business context and risk tolerance. AI can tell you what happened technically; it cannot tell you what a finding means for your specific business, contracts, regulatory obligations, or customer relationships.

Novel and adversarial situations. AI models are trained on historical patterns. Genuinely novel attack techniques, or attackers deliberately crafting inputs to evade detection, remain areas where experienced human analysts outperform automated systems.

Communication and decision-making under pressure. During a real incident, decisions about customer notification, regulatory reporting, and business continuity require judgment, accountability, and communication skills that fall outside what current AI tools do.

Strategic security architecture. Deciding how to design systems, what tradeoffs to accept, and how to balance security against usability and cost remains fundamentally a human decision-making process, informed by data rather than replaced by it.

A Practical Framing

The most effective way to think about AI in security operations today isn’t “replacement” — it’s capacity multiplication. AI-assisted tools let a small security team cover far more ground than they could manually, by handling the high-volume, pattern-based work and surfacing what genuinely needs human attention.

Why This Matters

Organizations that treat AI as a total replacement for security expertise tend to end up under-protected, with real threats slipping past inadequately tuned automation. Organizations that ignore AI entirely tend to be overwhelmed by alert volume and slower to detect real incidents. The organizations that do best combine both deliberately.

How We Help

Our approach integrates AI-assisted analysis throughout our assessments — from vulnerability prioritization to risk analysis — while every finding and recommendation is reviewed and contextualized by experienced security consultants before it reaches you.

[Button: Book a Free Consultation]