October 2026 | IT Support for Engineering Firms Salt Lake City | Cybersecurity Awareness Month | Security Myths
October is Cybersecurity Awareness Month — a good time for your engineering firm to take stock of what you actually know versus what you think you know about protecting your practice. Engineers don't accept a design assumption without checking it against the load case, so treat these common cybersecurity beliefs the same way: as hypotheses to be tested, not facts to be repeated. From the Civil 3D models on your file server to the CMMC obligations attached to your government contracts, a lot rides on getting the assumptions right.
When an unverified assumption goes unchallenged, it creates blind spots. And blind spots are exactly what cybercriminals look for. Knowledge gaps and comfortable assumptions are what make firms easy targets — not their industry, their project mix or their location.
The good news is that these gaps are simple to close once you know where they are. Here are six myths we hear from engineering firm principals regularly, along with the evidence against each one.
Myth 1: "Hackers Don't Target Engineering Firms"
Test this hypothesis against what your firm actually holds: proprietary calculations and design methodologies developed over years, structural models in RISA or ETABS, stamped drawings, geotechnical reports and — if you work on DOT, municipal or federal projects — government project data that may carry contractual security requirements, including CMMC for defense-related work. That is exactly the kind of intellectual property and controlled information attackers monetize.
It doesn't matter what disciplines you practice. If you have exposed accounts or vulnerable systems, bad actors will take advantage of them. Every engineering firm offers valuable project files and engineering documents, access to bank accounts, or entry points to clients, subconsultants and public agencies.
Fact: Hackers choose targets based on opportunity, not profile — and engineering firms present plenty of opportunity.
Myth 2: "Our Engineers Will Recognize a Phishing Email"
The days of obvious phishing emails full of typos from suspicious senders are gone. Today's emails are polished and personalized — a fake DOT project portal notice, a spoofed client invitation to a Newforma or ProjectSight workspace, or a counterfeit file-share link claiming to hold revised drawings can convince even a skeptical reviewer.
Thanks to AI, it's become harder to catch a scam email from the text alone. Instead, your engineering team needs to evaluate sender behavior the way they'd evaluate an input that doesn't match the rest of the data set. Ask whether the supposed sender would:
- Make an unusual request outside the normal project workflow
- Change payment instructions for a subconsultant or vendor
- Request sensitive project information or credentials
- Send a new or unusual login link to a "project portal"
If anything seems off, verify through a known channel before clicking or responding.
Fact: A convincing email can still be a scam.
Myth 3: "MFA Fully Protects Our Systems"
Multi-factor authentication (MFA) is important, but it's not invulnerable — treat it as one component with a defined function, not a complete system. Hackers use MFA fatigue to their advantage, counting on staff approving requests out of habit or annoyance. "Prompt bombing," for example, floods your phone with requests in hopes you'll approve access just to make them stop.
MFA is a tool, not a shield. Attackers are finding ways around weaker authentication methods, which is why MFA needs support from the security controls around it — especially where it protects remote access to design workstations, license servers and project management platforms like Deltek Vantagepoint.
Fact: MFA should be one element of a broader, coordinated cybersecurity strategy.
Myth 4: "Our Backups Have Us Covered"
Ask yourself: if your firm was hit with a ransomware attack tomorrow, could you actually restore your project archives — the Civil 3D drawings, the MicroStation files, the ANSYS and MATLAB simulation data that took weeks of compute time to produce? How long would it take, and would the restored files reference correctly?
A backup is great when you know it's going to work. A backup that has never been restored is an unverified assumption — and engineers don't stamp unverified assumptions. Knowing how long your firm would realistically be down, and which project deadlines that downtime would threaten, can save you significant time and money.
Fact: Having backups is not the same as being able to recover.
Myth 5: "Cybersecurity Is Only IT's Responsibility"
Your IT resources do a lot to keep your firm safe, but they can't control every click your engineering team makes. Cybersecurity decisions happen across every discipline and every project team, and it takes only one bad click to expose your systems — and your clients' project files and engineering documents — to threats.
For firms pursuing or holding government contracts, this stops being optional: CMMC makes workforce security awareness a documented, contractual requirement, not a suggestion. When everyone knows what to look for and when to ask for help, they become part of your firm's defenses instead of the gap in them.
Fact: Training your engineering team to make good decisions strengthens your security posture — and supports your compliance position.
Myth 6: "We Know What to Do If Something Happens"
It's Tuesday morning. Several engineers suddenly can't open the project drive. Deadlines on a DOT submittal are three days out. Many firms discover in that exact moment that nobody has answered the basic questions:
- Should staff shut down their workstations?
- Who calls IT?
- What do you do if communication systems are down?
- When does the insurance company get involved?
- Who notifies clients, prime consultants and agencies — and how?
Don't rely on memory in the moment. Have a documented incident response plan — the same discipline you apply to QA/QC procedures. If CMMC applies to your contracts, a documented and tested incident response capability isn't just good practice; it's required.
Fact: Your recovery plan shouldn't debut during an incident.
Frequently Asked Questions
Do you offer IT support for engineering firms and technical consultancies in Salt Lake City?
Yes. Qual IT provides IT support for engineering firms in Salt Lake City, including secure infrastructure for CAD and analysis software such as AutoCAD Civil 3D, Bentley MicroStation, RISA and SolidWorks, protection for project files and engineering documents, backup and recovery for project archives, CMMC readiness support and employee security awareness training.
What is the biggest cybersecurity mistake engineering firms make?
Assuming they're covered without verifying it. Untested backups of project archives, unexamined assumptions about staff readiness and security tools nobody monitors create a false sense of protection — which is often more dangerous than a known, documented gap.
How do I know if my firm's cybersecurity is actually working?
Through testing and review — the same way you'd validate a model: verified restores of project data, simulated phishing exercises, and a periodic, documented assessment of your tools, policies and response plans by a qualified IT security partner familiar with engineering company IT services in Utah.
Cybersecurity Awareness Starts With Verified Assumptions
Cybersecurity Awareness Month is about making sure the assumptions guiding your decisions would survive review. Myths are comfortable — they let you feel covered without checking the math. But cybersecurity gaps rarely come from a missing product. They come from believing you've already got it handled when you don't.
We work with Salt Lake City engineering firms to protect project data and support technical workflows. If any of these myths sound familiar, it's time to check them against the evidence.
Schedule a free 10-minute discovery call with Qual IT and we'll help you separate what's protecting your firm from what's only giving you peace of mind. Book your discovery call here.
