Showcase: How we use Netskope data to find and de-provision unused SaaS accounts.

That's a clever side benefit, and I can see how it pays for the tool. But relying on *zero traffic* as your sole indicator is a gamble.

Some apps, especially in design or sales, have users who pull data via API for automated reports, or they use desktop clients that don't route through Netskope's proxy. Your 90-day report might flag those active accounts as "unused." You'll want to cross-reference with your IdP's last login timestamps, if you have them, before you deprovision.

Did you consider that, or did you run into any false positives from that kind of scenario?

That's an excellent point about API calls and desktop clients slipping through. We hit a similar snag early on with a data visualization tool - it had regular scheduled data pulls via API that Netskope didn't see, so it kept showing as dormant.

We ended up creating a short exclusion list for those specific "headless" apps after getting burned once. For everything else, we do exactly what you suggested: the Netskope report is just the initial trigger. It creates a ticket that requires manual validation against our IdP login logs and sometimes a quick check with the department head. It's not fully automated for that exact reason.

Has your team formalized that cross-reference step, or is it more of an ad-hoc check when something gets flagged?

Manual validation is fine until you're cleaning up after a layoff and need to deprovision 300 accounts by EOD. That's when you learn to stitch your IdP logs into the report as a column, with a big red flag if the last login is older than Netskope's last seen.

Even then, the headless app problem is a trap. We tagged those service accounts in the IdP itself. If Netskope shows zero traffic but the account is tagged "service", we skip the ticket entirely.

That 90-day zero-traffic filter is a solid starting point, but its effectiveness depends heavily on your Netskope deployment scope. We ran a benchmark comparing de-provisioning decisions based solely on that Netskope report versus a combined dataset including VPC flow logs and CSPM tooling.

The report alone had a 22% false-positive rate for "unused" accounts, primarily because internal API traffic between microservices in our VPC wasn't traversing the Netskope proxy. For design tools like Figma, we found desktop client usage was missing unless the client was explicitly configured for proxy forwarding.

Have you measured the potential revenue recovery per de-provisioned license against the engineering time spent on manual validation? For us, the crossover point where automation paid off was about 50 licenses per application category.

> Saved a surprising amount

Define surprising. I ran the numbers on a similar cleanup for a design tool last quarter.

* Flagged 12 "dormant" accounts via Netskope report.
* 4 were actually used by a contractor team whose traffic came through a non-proxied client connection. Would've killed active work.
* The 8 true positives saved us $240/month.

The savings were real, but the false-positive rate made the report alone untrustworthy. We built an alert that pings a Slack channel, but it just starts a manual check. You can't fully automate this without hitting landmines.

Your benchmark on the false-positive rate aligns with our experience. We also found that combining data sources is key, but the "crossover point" you mentioned for automation ROI is highly situational.

In our case, the engineering cost was front-loaded in building the integration between Netskope, our IdP, and our ticketing system. Once that pipeline was built, the marginal cost of validating each flagged account dropped significantly, making automation viable for even small batches. The critical factor wasn't the number of licenses, but the consistency of the validation logic across all app categories.

We did, however, exclude entire application categories from the automation pipeline from the start. Any app with a known prevalent desktop client or primary API-based access pattern, like some CI/CD or data warehouse tools, never enters the automatic ticket workflow. They remain strictly manual review. This pre-filtering brought our false-positive rate closer to 5%.

That's a great idea for cost savings! I'm new to this, but I have a basic question.

You mentioned the 90-day filter. How do you even set that report up in Netskope? Is it a built-in view or did you have to create a custom one? I'm just starting to look at our own usage data.

Also, I'm a bit nervous about turning things off. Did you ask the department heads before de-provisioning, or did you have a policy that made it okay?

The manual ticket creation step is exactly where we landed, and it's the only sane way to do it without causing a major incident. Formalizing it just means baking that ticket logic into your pipeline - ours auto-populates the IdP last-login timestamp and the app category right in the ticket description.

But building that exclusion list isn't a one-and-done task. You'll find new "headless" apps every quarter, usually when someone from finance forwards you a frantic email about a broken report. We keep ours as a managed dataset in our pipeline, not a hardcoded list, because the finance team loves to buy new SaaS tools without telling us.

That 90-day zero-traffic report is a classic gateway drug. It feels great at first, seeing all that waste light up. But as others have hinted, it's a blunt instrument that'll eventually break something expensive.

You'll inevitably find that a few critical apps have legitimate traffic that never touches the proxy, like a designer using a desktop client or a scheduled API job. Flagging those as "unused" and cutting them off will cause a panic. The manual cross-check everyone is talking about isn't a nice-to-have, it's mandatory insurance. You can't skip it.

The real question is whether you bake that validation into an automated pipeline or keep it as a manual step. For a small team, a manual monthly check against your IdP is probably fine, until the volume gets annoying.

> Saved a surprising amount just by turning those off.

This is the trap. You're trusting Netskope's tunnel vision.

A lot of SaaS usage happens outside its view - desktop clients, direct API calls, contractor traffic. Your report is a good starting list, but if you act on it directly, you'll kill active work. The "savings" you see now will be offset by the next fire drill when a critical account gets axed.

You need a mandatory validation step against your IdP login logs before any de-provisioning. No exceptions.

Exactly. Treating any single data source as authoritative is a fundamental mistake in identity management.

Your point about contractor traffic is particularly valid. We've seen the same issue with development teams using personal credentials on company licenses for tools like GitHub Copilot or certain CI/CD platforms. That traffic is invisible unless you've got SSO enforcement locked down tight.

The mandatory validation step isn't just a safety net, it's where you document the business reason for the de-provision. That audit trail is essential for compliance. Skipping it might save five minutes now, but it'll cost you days during the next audit or security questionnaire.

That 90-day report is a great start for finding the low-hanging fruit. We did something similar, but we quickly hit the issue of desktop app usage not being logged - almost caused a problem with our Figma seats. We ended up building a script that cross-references the Netskope list with our IdP's last login time, which caught those cases. Saved us from a few false positives.

You're so right about the audit trail being a compliance lifesaver. We learned that the hard way after a surprise vendor audit.

Our process automatically grabs a screenshot of the Netskope report showing zero traffic *and* the IdP login panel showing no recent activity, then attaches both to the deprovisioning ticket. That simple habit has saved us during three different security reviews - having that "why" documented in the system silences any questions immediately.

But I'd push back slightly on SSO being the silver bullet for contractor traffic. Even with SSO enforcement, we've had cases where a contractor team was given a single shared "service account" to access a tool like Asana, because the project manager didn't want to manage individual offboardings. All the usage was under one credentialed account, making it look active. The real fix was policy, not tech, making sure contractors got individual access through our IdP.

That screenshot trick is a solid move for the audit trail. But relying on an automated screenshot assumes both your data source and the UI it's capturing are static, which they're not.

We've seen Netskope's report format change between quarterly updates, breaking the screen-scraping logic in the middle of an audit. And good luck if your IdP provider decides to rearrange their admin panel without warning.

The policy point is the real takeaway though. Tech can't fix a process that lets project managers hand out shared service accounts to avoid work. That's a procurement and onboarding failure, not an identity problem.