Simplifying Threat Detection in High-Risk Environments
Company
Bluebeam
Role
Senior Designer
Timeline
4 weeks
Released
July 2025
The tool
Bluebeam Revu is a PDF-based collaboration and markup tool designed for the architecture, engineering, and construction (AEC) industry. It helps users create, edit, annotate, and share project documents.
The business need
Enterprise customers need threat detection to meet strict IT security requirements, making it essential for Bluebeam to offer a built-in service that checked the compliance box while keeping collaboration seamless.
The challenge
How might we introduce security measures to meet business needs without overwhelming users or creating unnecessary friction?
Currently, Bluebeam lacks a dedicated threat detection mechanism, leaving users vulnerable to cybersecurity risks—particularly malicious PDF files that can serve as attack vectors. With Bluebeam handling a large volume of file uploads, there is a potential security gap that could compromise users’ data and trust.
Adding automated threat detection helps:
Protect users from malicious files without disrupting their workflows (hopefully)
Ensure compliance with enterprise security standards (SOC 2, ISO/IEC 27001).
Increase trust in Bluebeam as a secure collaboration platform.
Finding the goldilocks zone
This project was a balancing act: tip too far into interruption and users get annoyed, lean too far into silence and they miss the danger. The sweet spot? Just enough interruption to catch their attention, not enough to get in their way.
How do you warn users about malicious files without turning into antivirus software?
With the planning done, I turned to the big question: lock risky files away in quarantine, or let users keep working—just with a flashing caution sign?
Insight 🧠
Sharing this with stakeholders helped us align on scope. An administrative UI that allows users to review dangerous files was too much to take on for this project. (But a requirement for a quarantine-based experience)
Insight 🧠
Focus on clarity over explicit blocking—users cannot be locked out from their own content.
The Takeaway
To reduce friction, flagged files will remain available to users, even if detected as malicious. This approach ensures:
1. Users are not blocked from accessing critical files due to false positives or security restrictions.
2. A clear warning system informs users of potential threats, allowing them to make an informed decision before opening or sharing the file.
3. Admins or IT teams may (eventually) have control over restrictions, but default behavior should prioritize awareness over strict access denial.
Mapping out all of the existing UI’s gave me some ideas…
New Idea 💡
Represent a warning about the malicious file on the file management screen.
New Idea 💡
We could add some sort of warning upon opening the file itself, mimicking the conventions set forth by companies like Google.
Insight
Threat detection is not a one-time process—it continues beyond the initial file upload.
This is because:
New threats emerge over time, and files that initially seemed safe may later be identified as malicious.
PDFs and other documents can contain dynamic content, such as links, embedded objects, or scripts, which may be altered post-upload without modifying the file itself.
Threat intelligence databases are constantly updated, so periodic rescans ensure Bluebeam catches new risks as they are discovered.
To handle this, the system periodically polls files at different intervals:
Frequent scans in the first few days after upload.
Gradually decreasing frequency over time as file reputation stabilizes.
Insight
If we limit telling users that the file is good, we can prevent mistrust when the file is bad.
This leaves two options of for informing users of danger:
non-interruptive
interruptive
Non-interruptive presents a warning on the file itself and allows users to open it with no interruption.
Interruptive stops the user with a warning modal, forcing them to confirm that they want to open the file.
The Case for Stronger, Interruptive Warnings
Engineering raised a key concern: if a file is dangerous when opened, warnings can’t just live on the surface—they need to be clear enough to stop users from walking straight into trouble