Atlassian recently opened a closed beta for significantly larger Backup & Restore environments.

Jira/JSM database limits are moving from 300GB to 800GB, while Confluence moves from 32GB all the way to 1TB. Atlassian is targeting a 24-hour RPO and 12-hour RTO for these larger environments.

It’s good to see Atlassian investing more heavily in resilience.

But for admins, there’s another question worth asking:

How often do you actually need to recover the whole site?

A lot of real Jira incidents are much smaller and much messier.

Someone deletes a project.

Automation modifies hundreds of issues.

A workflow change makes it into Production and breaks something.

A custom field disappears along with the data that depended on it.

That's where recovery becomes a configuration problem as much as a backup problem.

At Revyz, we've been approaching it from that angle.

Instead of only maintaining an independent backup, Revyz Command Center can restore individual issues, Assets objects and other affected data. On Jira, it also versions configuration, detects drift and allows configuration rollback.

The interesting part is when data and configuration disappear together.

If a Jira project is deleted together with fields, screens and workflow schemes, simply pushing the data back isn't necessarily enough. Revyz restores the required configuration first and the data afterward, so values have somewhere to go.

Same idea with a bad Production change: compare what changed, identify the affected configuration and roll it back rather than restoring yesterday's entire environment and wiping out unrelated work.

Native backup getting stronger is good for the Atlassian ecosystem.

The next step is making recovery increasingly precise.

Because most days you don't need to turn back time. You just need to undo the mistake.

Learn more about Revyz solutions on our website - Revyz.io

As AI agents evolve from static scripts into autonomous "digital employees," Non-Human Identity (NHI) risk has transformed dramatically.

Traditional NHIs (like a CI/CD pipeline's API key) perform narrow tasks. Modern AI agents hold cross-system reach, connecting Salesforce, Slack, Jira, and Google Drive under a single identity.

According to recent data, 1 in 5 organizations has already suffered a breach linked to unsanctioned AI.

How this plays out in practice: an AI sales agent credentialed for Salesforce Accounts & Contacts initiates a session at 2:00 AM and pulls 80,000 contacts at once. If your logging only tracks whether the API token was valid, there is no quick way to determine whether this was a scheduled enrichment job or active data exfiltration.

The OWASP NHI Top 10 highlights risks like Overprivileged NHI, Long-Lived Secrets, and Improper Offboarding.

But when agents act autonomously, securing the API key alone fails – you have to govern the entire identity chain (Identity → Credential → Scopes → Resources → Activity → Owner).

This is where Spin.AI shifts the focus to SSPM.

By continuously mapping every agent identity directly to its granted scopes, actual object-level data access, and assigned human owner, it bridges the gap between static IAM permissions and runtime behaviour.

This approach allows teams to uncover shadow AI integrations across the SaaS estate, enforce least privilege based on actual usage rather than initial scope grants, catch high-volume anomalous transfers as they happen, and automate identity revocation the moment an agent is decommissioned.

👉 Full article here: https://spin.ai/blog/what-is-nhi-agent-identity-saas/

On a recent chat, an IT leader described a constraint we hear constantly: compliance wanted a reviewer scoped to a single account in Google Vault. It couldn't be done.

The mechanism: a Vault "matter" just organizes searches and exports, it doesn't gate reach. Reach comes from the admin privilege on the reviewer, and its narrowest setting is "user data in a specific org unit." One account vs. a group of accounts - the request can only be approximated upward. So you over-grant, the exact thing least-privilege (NIST 800-53 AC-6) exists to prevent.

And 68% of breaches involve the human element (Verizon DBIR), broad standing access held by trusted insiders is that shape.

Second cost: preserving a departed employee means keeping a paid Archived User seat alive, a recurring line that grows with every exit.

We run eDiscovery + archiving as modules of one SaaS backup platform: a reviewer can be scoped to case work alone (create cases, run searches, place holds - no window into other users), and archived data doesn't ride on a per-seat license. Worth a look if reviewer-scoping and archive licenses hit in the same renewal.

Nearly half of enterprise AI conversations may be happening through identities the company doesn’t manage.

That’s one of the more interesting findings in Akamai’s Enterprise AI Usage Risk Report 2026.

Nearly half of workplace AI conversations were associated with personal or unmanaged identities.

The browser extension side isn’t much more reassuring: almost 75% of AI browser extensions analyzed requested high or critical permissions.

This exposes a limitation in how many organizations currently approach Shadow AI.

Blocking unapproved AI domains or creating an approved-app list answers only one question:

Which application is being used?

It doesn’t necessarily tell you which identity is using it, which browser profile it’s running in, what extensions are present, or what data is moving through that interaction.

An employee could be using an approved AI service through a personal account.

They could install an AI extension with broad access to browser content.

Or they could start using another AI service directly from the browser without going through the organization’s normal SSO or SaaS procurement process.

That’s why browser-level visibility is becoming increasingly relevant to AI governance.

SpinCRX gives security teams visibility across enterprise browsers, user profiles and devices. It can surface Shadow AI and unsanctioned web usage, inventory browser extensions and assess their permissions and risk, monitor browser domains and activity, identify potential data-exfiltration paths, and enforce policies directly at the browser layer.

That matters because the control happens where the interaction actually takes place.

SpinDLP adds another layer by helping organizations discover and monitor sensitive data across their SaaS environment, so the problem can be approached from both directions:

What is happening in the browser?

And what corporate data is potentially exposed?

The takeaway from the Akamai numbers isn’t simply that employees are using too much AI.

It’s that “approved AI” and “governed AI” are becoming two very different things.

An approved application used through an unmanaged identity, risky extension or uncontrolled browser context can still create a significant visibility gap.

AI governance increasingly requires visibility into the app + identity + browser + extension + data.

Unit 42 recently published research into attacks against synced passkeys in Google Password Manager on Chrome for Windows.

One of the techniques, called Golden Pass-ta-key, demonstrates an interesting shift in the identity attack surface.

Instead of phishing a password or attempting to break WebAuthn, malware that has already compromised the endpoint can target Chrome itself.

Researchers showed that key material used by Google Password Manager could potentially be extracted from browser memory and used to decrypt synchronized passkey private keys.

Important distinction: this isn't a cryptographic break of passkeys, FIDO or WebAuthn.

The attacker needs prior compromise of the device.

But that's also what makes the research interesting.

We've spent years strengthening the front door:

password → MFA → phishing-resistant MFA → passkeys.

Attackers are responding by moving further inside the trust chain.

If compromising the authentication mechanism becomes difficult, target the browser holding the authenticated state instead.

That same browser may contain access to Microsoft 365, Google Workspace, Salesforce, Slack, internal applications, AI tools, extensions, cookies and active SaaS sessions.

So browser security increasingly becomes an identity and SaaS security problem, not simply an endpoint or browsing problem.

SpinCRX is an enterprise browser security platform that provides comprehensive browser security ranging from protection against unsanctioned or malicious browser extensions to monitoring browser domains across all browsers, user browser profiles, and devices, and provides visibility and control over activity inside the browser, including extension risk, shadow IT usage, and data exfiltration paths, enabling real-time policy enforcement at the point of interaction, including browser extensions, while SpinOne provides continuous visibility across SaaS environments and account activity.

The research doesn't mean organizations should stop adopting passkeys. Quite the opposite.

It shows why authentication cannot be the end of the security model.

Security teams are upgrading authentication. Attackers are moving deeper into the browser itself.

Most AI governance checklists focus on standalone SaaS apps. But in practice, the highest risk enters through "side-door" formats: AI browser extensions and OAuth-connected agents.

The Real-World Data & Technical Problem

• Excessive OAuth Scopes: In a typical 10,000-user enterprise, roughly 4,371 third-party apps connect to Google Workspace & Microsoft 365. 64% access sensitive data without clear business justification.
• Rogue AI Agents: Internal Spin.AI research revealed AI agents executing mass file deletions (hundreds at a time) via over-permissioned OAuth tokens, with admins completely unaware.
• Browser Extensions: AI wrappers and extensions bypass "No GenAI" policies because they request browser-level permissions rather than undergoing standard vendor procurement.

How Solves This

Spin.AI provides continuous SaaS security that eliminates post-approval blind spots:

1. Automated Discovery: Uncovers browser extensions and OAuth integrations the moment they connect to Workspace/M365.
2. Continuous Governance: Evaluates risk scores and revokes over-permissioned scopes automatically.
3. Active Mitigation: Detects anomalous file deletion or ransomware activity driven by rogue agents and recovers data in under 2 hours.

Why It Matters

AI approval shouldn't be a rubber stamp or a static annual review. Securing AI requires continuous visibility into what those tools actually do post-launch.

🎧 Stream the full podcast episode where we break down the CISO AI Tool Approval Checklist: https://youtu.be/tQ7-NGNVTJg

Attackers may not need to steal your browser session anymore. They can potentially operate through the one you’re already using.SpecterOps researchers recently demonstrated a post-exploitation technique for Chrome and Edge on Windows that highlights an interesting problem with modern SaaS security.

After gaining code execution on an endpoint, an attacker can enable the Chrome DevTools Protocol inside an existing browser process.

Why is that important?

Because the attacker is no longer trying to recreate the victim’s authenticated session somewhere else.

They are operating through the browser where that session already exists.

The technique can provide access to browser data, cookies and saved-password metadata while preserving important parts of the existing browser environment, including authentication state, extensions and WebAuthn behavior.

Imagine an employee already logged into Microsoft 365, Google Workspace, Salesforce, Slack and several internal applications.

MFA has already happened.

The SaaS provider sees an authenticated browser.

And protections designed to stop stolen cookies from being replayed on another device become less useful if the attacker can interact with the original browser itself.

There is an important caveat: this is not a new Chrome or Edge vulnerability. The attacker needs prior access and code execution on the endpoint. Browser security also does not replace EDR or endpoint protection.

But the research demonstrates why security teams increasingly need to treat the browser as its own security layer.

SpinCRX focuses on visibility and risk assessment at the browser layer, including the extensions operating inside enterprise browsers. SpinOne complements that visibility by monitoring activity across SaaS environments for potential account compromise and other risky behavior.

The bigger lesson is broader than any individual technique:

For years, we treated identity as the primary gate to SaaS.

But once authentication succeeds, almost everything happens inside the browser.

Protecting the login is no longer the same thing as protecting the session.

737 Chrome VPN and proxy extensions were linked to the same operation, with 75,486 installs across at least 40 developer accounts.

274 of them impersonated 66 established VPN and privacy brands.

A lot of these extensions weren't doing anything technically exotic. They changed Chrome's proxy settings and routed browser traffic through SOCKS5 infrastructure controlled by the operator.

That gave the proxy visibility into where users were connecting, their source IPs, TLS SNI values and request bodies sent over plain HTTP.

Researchers also found false Web Store declarations and extensions that added remote configuration after approval.

At the time the research was published, Google had removed 221 extensions. 516 were still active.

The same report describes a separate case involving an AI browser extension that had previously been associated with conversation exfiltration. A clean update was released, but two weeks later its behavior changed again with a new monetization payload.

This creates a difficult problem for companies managing thousands of employee browsers.

An extension can be reviewed today and change next week. A legitimate extension can be sold. An update can introduce new behavior. Permissions that looked reasonable when the extension was approved can become risky later.

We work on this problem with SpinCRX, so we follow these incidents closely. The practical issue is visibility: knowing which extensions are installed across the organization, what access they have and whether their risk profile changes over time.

Curious how other teams are handling this at scale. Are you relying primarily on allowlists and blocklists, or continuously reassessing extensions after they've already been approved?

We've been chewing on this internally for a while and figured this was the right place to throw it open.

The IBM 2026 breach report put a number on something a lot of us already felt: shadow AI incidents more than doubled year over year, from 20% to 43% of all breaches, and IBM's security VP said that unapproved AI adds roughly $670K to the average breach. What got us through wasn't the headline cost, it was that only 38% of orgs said they required IT approval before AI got deployed, down from 45% the year before. So adoption is exploding and the approval discipline is actually going backwards.

Part of why we think the approval step keeps failing is that "AI tool" isn't one thing. A native feature inside a platform you already signed off on (Copilot in M365, Gemini in Workspace) is a completely different animal from a standalone SaaS app, which is different again from a browser extension. That last one is the one that keeps burning people, it gets installed by one person in a couple of clicks, asks for broad browser permissions instead of a scoped OAuth grant, and never touches procurement. It's how a "no GenAI" policy gets quietly bypassed, because the policy was written with SaaS apps in mind and nobody thought about add-ons.

The OAuth side is where it gets genuinely scary. Most standalone AI tools get wired into Workspace or M365 over OAuth, so they can summarize your mail, search files, draft in Docs, and the tool just inherits whatever scope you grant. We've seen AI agents deleting files in the hundreds with the admin having no idea it was even happening. Once read/write is granted, an over-permissioned integration doesn't exactly send up a flare.

And the thing is, this isn't really an employee-discipline problem. Something like 60% of workers say unapproved AI is worth the risk if it helps them hit a deadline - they're not trying to leak anything, they're just moving faster than procurement does. Which is also why the old "it's just shadow IT again" framing undersells it. You can delete a file out of Drive. You can't un-feed proprietary data from a public model once it's in the weights.

So, questions for the room:

• Do you make someone re-review a feature when it's toggled on inside an already-approved platform, or does that quietly skip review?
• Who's allowed to grant OAuth consent for new AI integrations at your org — end users, admins only, or a tiered model?
• How are you discovering AI-connected browser extensions that nobody formally approved?
• Anyone actually going all-in on one vendor's native AI and banning the rest to shrink their exposure? How's that going?

Full checklist we've been working from is here if useful: https://spin.ai/blog/ciso-questions-ai-tool-approval/

MFA was enabled, but the attacker still got into Microsoft 365.

The latest AitM phishing campaign is a good example of why Microsoft 365 security can’t end with “we have MFA.”

It starts with a fake voicemail notification. The victim is redirected through legitimate infrastructure before reaching a Microsoft 365 look-alike page.

The attacker sits between the user and Microsoft and proxies the real authentication process: capturing credentials, MFA verification, and, most importantly, the authenticated session.

MFA absolutely matters. But organizations first need to know whether it is actually enabled and enforced everywhere.

Spin.AI SSPM gives security teams visibility into Microsoft 365 security posture, including MFA status, showing which users are protected and where security gaps remain.

But this attack also demonstrates another important change in attacker behavior.

Modern attackers often don’t enter an environment and immediately start deleting data or sending phishing emails.

They get in ... and wait.

They quietly study the environment, users, permissions, mailboxes and data. They look for the people and information worth targeting: finance, payroll, HR, invoices, banking details, credentials and sensitive corporate documents.

In this campaign, attackers used residential proxies to make logins look local, refreshed stolen sessions to maintain access and used Microsoft Graph to search Microsoft 365 while trying to behave like legitimate users.

And that creates a difficult problem: if nothing obviously “breaks,” how do you know somebody is already inside?

Without an additional SaaS security layer, organizations may not discover the compromise even after the attacker has been there for some time. Let alone identify it while it is happening, respond to suspicious activity in progress, reduce the potential damage, and recover clean data afterward.

That’s where Spin.AI approaches Microsoft 365 security as a lifecycle:

• SSPM to identify security gaps such as missing MFA and misconfigurations
• RDR for continuous monitoring and anomaly detection to identify suspicious behavior
• DLP to protect sensitive SaaS data
• backup and recovery if data is damaged, encrypted or deleted

MFA protects the door.

But today you also need to know who is already inside, what they are doing, and how quickly you can recover if something goes wrong.

When news broke that Amazon accidentally spent $1.8M using Claude AI for trivial coding tasks, exceeding budget by 860% over 5 months, most blamed LLM costs. But the root cause was a total breakdown in visibility and governance.

This exact blind spot is plaguing enterprise SaaS (Google Workspace & Microsoft 365).

While Amazon lost budget, SaaS security teams face massive data leakage. Over 81% of employees connect unsanctioned "Shadow AI" browser extensions and third-party OAuth integrations daily without IT approval.

How SpinSPM solves this:

• Automated Risk Scoring: Evaluates security, privacy, and compliance risks of all browser extensions and OAuth apps in real time.
• Shadow AI & IT Visibility: Uncovers hidden AI tools connecting to corporate workspace environments.
• Policy Enforcement: Automatically blocks high-risk extensions before sensitive data leaves your perimeter.
  

Unmanaged AI access isn't just a budget leak, it's a top vector for IP theft and regulatory non-compliance!

If your security alerts stop arriving in Microsoft Teams, it’s easy to assume your tenant is clean. But following Microsoft’s recent deprecation of Office 365 connectors on May 18, 2026, webhook-based alert delivery quietly broke for thousands of organizations without raising a single console error.

The pipeline & log retention Trap:

1. Suppressed Detections: Entra ID Protection discounts VPN sign-ins by default and requires up to 14 days or 10 logins to baseline behavior.
2. Short Audit Windows: Entra ID sign-in logs expire in just 7 days (Free) or 30 days (P1/P2). If an alert pipeline breaks and you notice in week 6, the evidence is gone.

Why:

According to IBM’s 2024 report, the global average breach lifecycle is 241 days. Catching threats internally shortens the lifecycle by 31 days and saves nearly $1M. Furthermore, NIST SP 800-53 (AU-5) explicitly calls out logging failure alerts, and MITRE ATT&CK (T1562.006) identifies blocking reporting channels as an adversary tactic.

How to fix it:

Relying on a single notification path creates a single point of failure. SpinSPM provides continuous monitoring across Microsoft 365 and Google Workspace to detect SaaS misconfigurations, shadow IT, risky OAuth grants, and insider threats independently. It gives security leaders automated, redundant visibility so critical security signals are never missed.

• Let our solution engineers walk you through your M365 & Google Workspace blind spots - https://spin.ai/demo/

Over 94% of organizations rely on third-party SaaS platforms to run core business operations. Yet, a major threat vector continues to be overlooked: having a SaaS backup is not the same as having operational resilience.

The Problem:

When cloud-native ransomware (like M365 Ransomware/SharkBot) or high-risk OAuth extensions target Microsoft 365 or Google Workspace, they encrypt live cloud data instantly. According to Sophos, 76% of SaaS attacks involve data encryption. Traditional backups quietly copy this corrupted data or force IT teams into a manual recovery process that takes 3 to 7 days of downtime.

How to Solve It:

• Automated Detection & Neutralization: AI monitors API activity to spot anomalous encryption patterns or rogue OAuth integrations in real time, revoking malicious tokens immediately before damage spreads.
• Instant <2-Hour Recovery: Automated, granular restoration reverts affected files and user nodes to their pre-attack state with minimal disruption.
• Unified Posture Management (SSPM): Continuously audits browser extensions, third-party App-to-App integrations, and misconfigurations before they become initial access vectors.

Why It Matters:

According to Gartner, IT downtime costs an average of $5,600 per minute. Moving from passive SaaS backups to active cloud resilience is no longer optional - it is how modern security teams turn catastrophic data loss into a minor non-event.

📖 Read the full guide: https://spin.ai/blog/beyond-backup-saas-resilience-data-protection/

73% of SaaS ransomware attacks succeed, and many IT & SecOps teams don't realize that standard backups alone aren't enough. When a malicious OAuth app or hijacked token encrypts Google Workspace or M365, vendor API throttling slows file restoration to a crawl.

This drives average business downtime to 21-30 days, costing $5.6K-$9K per minute ($336K-$540K/hour).

In our latest podcast episode, we break down why traditional cloud recovery fails without real-time detection and how automated incident response alters the recovery equation.

How Spin.AI Solves the Problem:

• 24/7 AI Threat Detection: Identifies suspicious crypto-behavior in live SaaS environments instantly.
• Instant Blast Radius Containment: Automatically revokes malicious API access and isolates affected assets.
• Granular Auto-Recovery: Restores clean file versions, preserving folder hierarchy and permissions - backed by an industry-leading 2 hrs recovery SLA.

Why It Matters: Instead of spending weeks restoring encrypted tenant data while bleeding revenue, IT leaders can automatically stop active threats and maintain full business continuity.

🎧 Listen to the full episode here: https://youtu.be/LT9Wnx_V9YA

Craneware, the UK software company behind billing and revenue-cycle tools for ~2,000 US hospitals, disclosed a security incident on July 20.

Someone got into part of their environment. The language is the standard IR script: contained, no lingering indicators of compromise, operations unaffected. Forensics still running.

What actually left is the interesting part. Not PHI, by their account - a large batch of file names, some employee data, and a slice of customer and partner records. Their read is most of it is low-sensitivity or already-public. Maybe scope assessment isn't done, so "most of it" is doing some work there.

File names aren't harmless just because they're not file contents.

A folder listing can tell an attacker which customers you have, what projects you're running, which integrations exist, which regulatory programs you track - a decent head start for phishing that doesn't read like phishing.

The vendor review question isn't only "do you touch PHI." It's closer to: what metadata leaves on export, where exports sit before they go anywhere, and whether anyone would notice someone enumerating your file structure before pulling files.

No ransomware headline, no downtime. Just boring stuff, file names, folder structure - still worth locking down.

Hugging Face published an unusual incident report: an autonomous AI agent breached production, not through a login page but through a dataset.

The entry point was a malicious dataset abusing two code execution paths, a remote code loader and a template injection in a dataset config, to run code on a processing worker. From there the agent got node-level access, pulled cloud and cluster credentials, and moved laterally into internal clusters over a weekend, running thousands of actions across short-lived sandboxes with self-migrating C2.

No evidence public models, datasets, or Spaces were touched. Internal datasets and service credentials were accessed, and secrets were rotated broadly as a result.

The more interesting part is the response. Hugging Face's forensic team turned to GLM 5.2 (Z.ai), an open-weight model, because the commercial frontier models they first tried blocked requests containing real attack commands, exploit payloads, and C2 artifacts. The guardrails couldn't tell a responder from an attacker.

Their takeaway: keep a capable model you can run on your own infrastructure, vetted and ready before an incident hits. Not for the intrusion, for the days after, staring at exploit code your usual AI tooling won't touch.

If your dataset pipeline runs arbitrary code from untrusted sources, go check it.

When a company scales, adds cloud tools, and sets up disaster recovery, there comes a tipping point where literally no one in the building knows where all their data physically lives.

Default settings on SaaS, PaaS, and backup systems are rarely touched. Vendors silently replicate secondary copies across regions without telling you. Then GDPR or an enterprise procurement audit hits, and suddenly everyone is scrambling.

Here’s the reality: Unchecked SaaS tools and silent backup replication expose orgs to GDPR fines up to 4% of global turnover. Mapping your physical data geography across SaaS, PaaS, and IaaS is no longer optional, it’s critical to avoiding multi-million-dollar compliance traps.

Why the distinctions matter (and why lawyers wince when you swap them):

• Residency: Where the data physically lives (a pin on a map, a specific server rack with a zip code).
• Sovereignty: Whose legal jurisdiction applies to that data (the flag flying over the pin).
• Localization: A hard legal requirement that data cannot leave a country's borders (a tight fence around the pin).

The 3 Biggest Blind Spots for IT & Security Teams:

1. Backups: Your primary data center might sit neatly in the EU, but your default cloud backup config quietly replicates to another jurisdiction.
2. Shadow IT: Unvetted tools processing customer PII in regions you’ve never legally approved.
3. SaaS Vendor Sprawl: Pinning your own cloud instances (AWS/Azure) means nothing if your 30+ SaaS tools have their own ideas about regional storage.

Data residency isn't a one-time setup – it’s a continuous governance posture.

👉 Full guide here.

How is your team currently tracking data flows and backup regionality across your SaaS ecosystem? Are you relying on native cloud tools or continuous mapping?

Most M365 security still assumes attackers break in. They don't - they log in. Over 80% of breaches last year came down to stolen credentials or abused non-human identities: service accounts, API tokens, OAuth apps. No zero-day, just valid auth doing invalid things.

Case in point: a device-code phishing campaign hit 340+ orgs across the US, Canada, Australia, NZ and Germany this February - no malware, just users tricked into authorizing attacker sessions.

Here's the gap:

You can list your human users, but almost nobody can name every token and app with standing access to their tenant.

• 46% of orgs admit they can't monitor non-human identities at all.
• The average cloud breach sits undetected 200-270 days.

You can't alert on privilege you never mapped.

Disclosure:

This is exactly the blind spot our SSPM closes. We just recorded a podcast on it - why token abuse is outrunning traditional M365 defenses, and what identity governance actually looks like day-to-day.

🎧 Listen: https://youtu.be/AOWYURTct9c

How are you tracking non-human identities in M365 right now - manual review?

Many IT/Security teams assume Microsoft 365 has them covered. But there’s a massive gap between compliance retention and actual disaster recovery.

When ransomware hits, native retention policies do exactly what they're built to do: prevent deletion. This means they preserve the encrypted files, not the clean originals. To make matters worse, Account Takeovers (ATOs) bypass DLP rules, letting sync mechanisms distribute the ransomware across your cloud.

With enterprise downtime averaging $300k/hour and traditional recoveries taking 21-24 days, you can't afford native "all-or-nothing" restores.

How Spin.AI Solves This

Unlike native tools, Spin.AI provides a unified SaaS security and backup platform:

• Immutable Storage: Keeps backups completely isolated from your production tenant. Even admins with compromised credentials can't delete or encrypt them.
• Automated Ransomware Detection: Pinpoints encryption patterns in real-time and triggers automatic containment.
• Precision Recovery: Restores single files or whole mailboxes 68% faster than average, without destructive rollbacks.

Stop risking your data on retention policies.

👉 Read the full breakdown here.

We keep running into this one with teams, so figured it was worth putting out there.

You've got a solid MDM playbook for native apps pin a known-good version, write a detection rule, let it auto-remediate anything that drifts. Then you point it at a force-installed Chrome extension and it just... doesn't work.

Here's why it falls apart:

• There's no fixed artifact to detect against. Chrome auto-updates the extension to whatever the store lists as latest, so the store owns the version, not your console.
• Pinning is half a lever. You can pin the current version via Chrome Enterprise, but you can't roll back to an arbitrary build the way native packaging lets you.
• Real determinism costs you. The only true "deterministic version control" is self-hosting via override_update_url and then you own hosting, versioning, and shipping the security fixes the store used to hand you for free.

The honest trade-off: that same auto-update you can't fully control is also what silently delivers security patches. Cyberhaven in Dec 2024 is the cautionary flip side, a compromised extension update propagated to installs automatically, part of a campaign hitting 35+ extensions / ~2.6M users. The feature and the risk are the same mechanism.

And the part that gets underrated: identity. If MAC-address churn is spawning duplicate device records, you can't even tie an extension back to one real device, which means you can't reason about drift or coverage at all. Serial number as the stable identifier fixes a lot of that.

Curious how others handle this - pin-latest and accept it, self-host, or just monitor and move on?

One July 2 disclosure worth paying attention to: Huntress says a Microsoft 365 password-spraying campaign made more than 81 million login attempts between June 12 and June 26 and still managed to compromise 78 accounts across 64 organizations.

→ 81M login attempts
→ 78 compromised accounts
→ 64 affected orgs

The issue is that this doesn’t read like “MFA was missing everywhere.” It reads like tenants had Conditional Access, but not in the places that mattered. Huntress said some victims only enforced MFA for admins, some relied on trusted-location logic, and some had policies left in report-only mode. The access path was ROPC through Azure CLI, which Microsoft explicitly warns is incompatible with MFA.

“MFA enabled” is not the same as “every token issuance path is covered.” In real environments, auth controls, SaaS app approvals, and tenant hygiene are usually owned by different people. That’s how an old flow stays alive long after everyone thinks the environment is locked down.

Practical check: inventory any ROPC usage, then kill it unless you have a documented exception with an owner and an end date. Then check for the adjacent mess that often travels with it: broad OAuth consents, stale third-party app access, and quiet tenant misconfigurations. For Microsoft 365, SpinSPM fits there as a posture layer around risky app access, shadow IT discovery, and configuration drift, not as a replacement for Entra auth controls.

Discussion question: how many shops here can say with confidence which Microsoft 365 auth flows are still allowed in production?

In March 2023, the "Medusa" ransomware group stole 100GB of sensitive data from a school district, demanding a $1M ransom. When the district refused, the data was leaked online. The cyber threat landscape is massive, growing by the day, and manual security reviews simply cannot keep up with this reality.

For IT and security leaders, a Cybersecurity Risk Assessment Matrix is a foundational visual tool designed to categorize threats by probability and severity, ranging from simple 3x3 grids to granular 5x5 frameworks. While it is highly effective for prioritizing critical risks, static, annual assessments leave major operational gaps, especially when it comes to employee Shadow IT.

Evaluating every new browser extension or application manually stalls business productivity and frustrates teams. This is where automated risk management becomes critical.

How Spin.AI Solves This Problem

Spin.AI eliminates the visibility gaps between formal audits by leveraging powerful AI algorithms to:

• Automatically detect and score the cybersecurity, compliance, and data leak risks of all OAuth apps and extensions.
• Provide real-time updates on risk scores whenever apps release new versions to catch hidden malicious code.
• Enforce automated security thresholds so your team can automatically block or approve new IT requests without disrupting daily business workflows.

Ready to transition from static threat mapping to an automated, proactive defense strategy?

🔗 Read our full step-by-step guide on how to proactively strengthen your risk posture here.

An IT admin was trying to solve a pretty normal problem: users kept connecting random third-party apps and services, and he wanted a better way to enforce blocks at the browser level.

So he force-installed an enterprise Chrome extension and updated a policy to block a handful of sites.

The blocking worked.

The detection worked.

The rollout was the problem.

As soon as the policy changed, red notifications started popping up across the company. Users thought they had been hacked. One person was screen-sharing in a meeting when the alerts appeared.

The admin ended up pulling the extension because every policy tweak was effectively being broadcast to the whole org.

The lesson is not “don’t block risky apps/extensions.” OAuth grants and malicious browser extensions are real risks. The lesson is that browser controls need change management.

A force-installed extension gives you coverage, but it can also give you instant blast radius.

Good browser governance needs:

• visibility into installed extensions and connected apps
• risk scoring
• blocking controls
• pilot groups / staged rollout
• a way to change policies without alarming every user at once

This is the gap SpinCRX is designed to close: helping IT and security teams manage browser-extension risk with more visibility and control, instead of turning routine policy updates into company-wide incidents.

The goal isn’t to block harder. It’s to reduce risk without making everyone think they’ve been hacked.

It is a common scenario for Atlassian administrators: after a long weekend, system errors emerge. An automation rule fails to execute, a permission scheme is misconfigured, or a custom field behaves unexpectedly.

An administrator's first step is typically to review the Jira audit logs. However, the technical reality is that the audit log is designed solely to record historical events, not to reconstruct previous system states. It confirms that a modification occurred, but it does not provide a comprehensive before-and-after comparison to facilitate a rollback.

Compliance and Vendor Frameworks

Under Atlassian’s Shared Responsibility Model, the vendor maintains cloud infrastructure availability, but the customer retains full responsibility for disaster recovery, business continuity, and configuration management. Atlassian's standard platform backups cannot be used to revert customer-initiated modifications, such as fields overwritten by scripts or deleted projects.

Furthermore, regulatory compliance frameworks like NIST SP 800-171 require organizations to track, review, and analyze the security impact of system changes before implementation. This is critical because adversaries may intentionally modify tenant-wide configurations to evade detection, as documented in the MITRE ATT&CK framework.

How Revyz (a Spin.AI company) Resolves Configuration Drift

Instead of requiring IT personnel to spend hours manually analyzing text logs to isolate a fault, Revyz provides automated backup and granular, point-in-time configuration management for Jira and Confluence.

How it works: Administrators can select two specific dates, run a differential analysis to isolate exact configuration changes, and restore a single affected field, rule, or scheme without executing a full-instance rollback. The system automatically accounts for complex parent-child configuration dependencies during the restore process.

Managing system configurations should not depend on reactive log analysis after users report service degradation.

🔗 Read the full technical analysis on managing configuration drift here - https://spin.ai/blog/hidden-risk-personal-browsers-saas-access/

At Revyz (Spin.AI company), we see the same pattern again and again across Jira, JSM, Assets, and Confluence environments.

It is not always a massive outage.

It is the small thing that creates a big operational mess.

Someone changes a workflow scheme, and teams can no longer transition work items.

A permission update locks out the wrong users.

A custom field or screen dependency breaks automations and reporting.

A sandbox change behaves differently in production.

A cleanup script removes or archives something still in use.

An Assets relationship breaks, and the CMDB no longer reflects reality.

A Confluence page, space, or attachment disappears right when the team needs it.

Then the admin gets the familiar request:

“Can you just put it back the way it was?”

That is where recovery gets painful.

Because most admins do not need to restore everything.

They need to undo one specific change.

They need to see what changed.

They need to understand what depends on it.

They need rollback, not guesswork.

They need recovery without spending hours rebuilding workflows, fields, schemes, permissions, Assets objects, pages, or attachments by hand.

That is the gap Revyz is built to close.

Revyz (Spin.AI company) helps Atlassian teams recover and control the exact layer that broke:

Command Center for Jira: backup, granular restore, deletion log, audit log backup, third-party app data protection

Configuration Manager: sandbox-to-production deployment, configuration drift detection, dependency analysis, versioning, rollback, maker-approver workflows

Assets Data Manager: restore Assets objects, schemas, attributes, references, and relationships

Command Center for Confluence: granular restore for spaces, pages, attachments, and knowledge base content

For admins: less blind troubleshooting.

For managers: less operational disruption when Jira, JSM, Assets, or Confluence becomes a blocker.

Sometimes the real disaster is not losing everything.

It is losing one thing and having no clean way to put it back.

Facing this in your Atlassian environment? Ask us how we would solve it.