Gartner’s How to Achieve the Minimum Viable AI Governance
Blog
SaaS Security Reform: What JPMorgan’s Warning Gets Right
Config hardening
Operational Excellence
Risk Management
When JPMorgan Chase sounds the alarm, we should all pay attention.
In a powerful open letter, the firm argues that the SaaS delivery model, while transformative, is eroding fundamental security boundaries and introducing systemic risk at a scale the industry is not prepared to handle.
It's not an altogether unfamiliar warning. Over the years, we've seen many security insiders comment on the potential dangers of letting current trends continue unabated. What sets this letter apart though was not only where it came from — a giant of global finance and trade — but the fact that it was not dealing in hypotheticals.
JPMorgan is talking about very real and growing costs to their business, requiring them to:
- Respond to compromised third-parties when those SaaS providers ensnared JPMorgan data and system in their problems
- Isolate vendors, cutting off access or removing integrations
- Dedicate significant internal resources to clean up and mitigate vendor fallout
It's placing an unreasonable burden on the business and appears to be increasing in frequency. Which is why JPMorgan took the bold step of publicly calling out software providers, challenging them to do better.
To abandon fragile trust models. To rebuild security architectures that can withstand the realities of SaaS sprawl, token-based trust, and identity-driven integration. And most importantly, to prioritize secure-by-default design.
At Remedio, we know better than anyone just how not secure-by-default most devices, systems, and environments are. In fact, insecure defaults are a huge part of the overall configuration security challenge that we were founded to solve.
Unfortunately, the gap between the current reality and the secure-by-default paradigm that JPMorgan called for is very big. And it's costing companies dearly, with an estimated 15% of all breaches stemming from insecure defaults.
Security Design and Defaults Aren't Keeping Up
It's fairly difficult to argue with the point that legacy assumptions about endpoint hardening, segmentation, and trust boundaries don’t hold up in a SaaS-first world. While integration, speed, and collaboration have accelerated, the hygiene and governance of security configurations — especially those enabled by default — remain dangerously misaligned.
As JPMorgan rightly points out, the convergence of authorization and authentication, paired with over-permissive defaults and token-based integrations, has created a perfect storm.
It's why we made Remedio to proactively detect and remediate insecure configurations in real time across endpoints, environments and identity systems. By injecting greater visibility and measurability into your cyber hygiene efforts, we help you take concrete hardening steps before the storm hits.
Secure-by-Default Must Be More Than a Slogan
JPMorgan is challenging the industry to up its game and deliver products that are secure-by-default. The inconvenient truth however is that despite plenty of vendor claims to the contrary, we're nowhere near that today.
To the contrary, most ship their products with problematic defaults and settings more suited to convenience than security. When JPMorgan says “we need vendors to step up,” they’re right. But even if the industry responds positively to JPMorgan's call for reform, it will be years until we bear the fruit of that response.
Where does that leave us in the interim? What do we do with all the insecure-by-default software already active in our networks? The misconfigurations are live. The risk is growing — and no one even knows where it all lays.
At Remedio, we systematically seek and close any gaps between “what’s secure by default” and “what’s running in production”. Configuration drift, excessive permissions, and misaligned policies aren’t minor missteps — they are systemic weaknesses waiting to be exploited.
With Remedio, organizations can:
- Detect and fix insecure endpoint configurations before they give attackers a foothold in your network.
- Validate that security settings match policies and enforce them continuously, not just during security audits.
- Eliminate configuration drift at scale, even across thousands of decentralized devices and users.
- Ensure identity integration is hardened, not just assumed.
Shared Responsibility, Backed by Visibility and Control
JPMorgan’s letter is a call for change. A demand for shared responsibility. But shared responsibility is meaningless without shared visibility and control. The stakes are clear. The risks are real. And the time to act is now.
We join JPMorgan in calling on SaaS providers to do better — but we also empower customers to take control today. Because security is not just a vendor problem. It’s a hygiene problem. A configuration problem. A visibility problem.
And it's entirely solvable.
We know it is because we've solved it. Over the years, we've helped many major enterprises uncover and resolve thousands of misconfigurations across systems they believed were secure. We empower them to take control back — not just from attackers, but from blind spots, defaults, and unchecked assumptions.
Together, we can make secure-by-default a reality!
FAQ
Why are security misconfigurations considered an operational problem rather than just a security issue?
Misconfigurations typically arise from operational activities such as deployments, policy changes, software updates, or infrastructure modifications. While security teams detect the resulting risk, preventing configuration drift requires collaboration between IT, operations, and security. Organizations that treat misconfigurations as an operational discipline can reduce recurring exposure instead of repeatedly responding to the same findings.
How does configuration drift increase cyber risk over time?
Configuration drift occurs when systems gradually deviate from approved baselines through routine changes, manual fixes, or inconsistent administration. As drift accumulates, previously secure systems become increasingly vulnerable, compliance gaps appear, and security teams spend more time investigating recurring issues instead of reducing overall risk.
Why isn't periodic configuration auditing enough?
Point-in-time assessments only show the environment at the moment they are performed. New misconfigurations can appear minutes later through software updates, administrator actions, or infrastructure changes. Continuous monitoring and validation provide ongoing visibility so organizations can detect and remediate new configuration issues before they become persistent risks.
What makes misconfiguration remediation difficult at enterprise scale?
Large organizations manage thousands of devices with different operating systems, applications, business owners, and operational dependencies. Fixing a configuration without understanding those dependencies can disrupt business operations. Effective remediation requires validation, dependency awareness, staged deployment, and rollback capabilities to reduce operational risk while improving security.
How should organizations prioritize which misconfigurations to fix first?
Priority should be based on exploitability, business impact, and operational context rather than severity scores alone. The most valuable remediation efforts focus on exposures that attackers can realistically exploit and that protect critical business services, reducing overall exposure without introducing unnecessary operational disruption.
What capabilities should organizations look for in a configuration security solution?
An effective platform should continuously monitor for configuration drift, enforce approved baselines, validate remediation before deployment, support automated rollback, and operate across heterogeneous environments. It should also align with frameworks such as CIS, NIST, and STIG while enabling safe, continuous enforcement instead of relying solely on periodic assessments.
About Author
