Demand Built In Safety From Your Software Vendors.
Written By: AKATI Sekurity Insights Team | Cybersecurity Consulting & MSSP Experts
Reading Time: 5 minutes
What You Need to Know: Every software product makes a fundamental choice during development: build security into the architecture from the first line of code (secure by design), or build features fast and add security settings customers can configure later (secure by default). This distinction determines whether your software gets hacked, whether you face lawsuits, and increasingly, whether regulators allow you to sell at all. This guide explains the difference using real-world disasters, shows why "secure by default" is becoming legally insufficient, and reveals what secure-by-design actually looks like when companies do it right.
The Thermostat That Helped Hackers Break Into a Casino
October 2017. A North American casino. Somebody managed to steal the high-roller database—names, addresses, gambling habits, and financial information of the casino's wealthiest customers. The casino had invested millions in cybersecurity. Firewalls. Intrusion detection. Security teams. So how did attackers get in? Through the lobby aquarium's smart thermostat. Yes, really. The thermometer. The device monitoring water temperature for the fancy fish tank in the casino lobby was connected to the internet so aquarium maintenance staff could check it remotely. Made sense. Convenient. Efficient. Except that smart thermostat was built with what's politely called "secure by default" thinking—meaning the manufacturer built all the features first, then added some security settings customers could configure if they bothered. Default password was probably "admin" or "password." Nobody changed it. Aquarium guy didn't know he needed to. Why would he? He maintains fish tanks, not computer networks.
Attackers found the thermostat on the internet, logged in with default credentials, used it as a stepping stone into the casino's network, and worked their way from the fish tank to the high-roller database. The thermostat wasn't broken. It worked perfectly for its intended purpose—monitoring water temperature. But it was fundamentally designed in a way that made it a security liability. This is the difference between "secure by default" and "secure by design," and it matters way more than most people realize. Let me tell you why through some stories that'll make you want to check every smart device in your house (and your office) right now.
Secure by Default: The Illusion of Protection
Here's how "secure by default" thinking works. A company builds a product—let's say a network router, security camera, or enterprise software application. The primary goal is features and functionality. Get it working. Make it do cool things. Make it easy to set up and use. Security is added afterward as configuration options. The product ships with security features available, but they're settings customers need to enable, configure, or customize. The theory is: we've provided security options, so if customers get hacked, that's on them for not configuring things properly. See the problem? You're putting the burden on customers—many of whom have no idea what they're configuring or why. It's like selling cars with airbags included but deflated, expecting every driver to know how to properly inflate and activate them before driving.
Real-world example: A popular business video conferencing platform (we won't name names, but you've probably used it) originally shipped with "secure by default" thinking. By default, anyone could join meetings if they guessed the meeting ID. Encryption was available but not enabled by default. Waiting rooms existed but were optional. Privacy settings could be configured but weren't enforced. In early 2020, when suddenly millions of people started working from home, chaos ensued. Uninvited strangers crashed meetings ("Zoom-bombing" became a term). Sensitive business discussions were exposed. The company scrambled to change defaults, but the damage was done. The product was designed with convenience first, security second.
Another example closer to industrial environments: Building automation systems—the software controlling HVAC, lighting, and access controls in office buildings. For years, these shipped with default passwords like "admin/admin" or "1234." The systems had security features. You could change passwords. You could configure access controls. You could enable encryption. But all of these were optional, requiring building operators to understand cybersecurity and take action. Most didn't. Research in 2023 found thousands of building control systems accessible on the internet with default credentials. Not because the products were broken. Because they were designed assuming customers would handle security themselves. That's "secure by default" thinking—and it fails in practice because most customers either don't know what to do, don't have time, or don't think it matters until they're hacked.
Secure by Design: Building Safety Into the Foundation
Now let's talk about the alternative. "Secure by design" means security is fundamental to the product architecture, not an optional add-on. Security decisions get made during initial design, not after features are built. Developers ask "how could this be attacked?" before writing code, not after shipping. The product ships in a secure state without requiring customers to become security experts. Features that could be dangerous simply don't exist unless they can be implemented safely. Think about modern cars. Seatbelts aren't optional accessories you can install if you feel like it. Airbags aren't settings you configure. Anti-lock brakes aren't features you enable. These safety systems are fundamental to vehicle design. They work automatically. You'd be shocked if a car manufacturer said "well, seatbelts are available, but you need to configure them properly or they won't work in a crash."
That's secure by design—safety is intrinsic, not optional. Apple's iMessage provides a good example from consumer technology. When iMessage launched, end-to-end encryption wasn't a setting users could enable. It was fundamental to how the system worked. Messages between iMessage users are encrypted automatically. Users don't configure anything. They don't make choices about security settings. It just works securely by default because security was designed into the architecture from the beginning. Could Apple have built iMessage without encryption initially, then added it as an optional feature later? Sure. Lots of messaging apps did exactly that. But Apple made a design decision: this will be secure from day one, and users won't need to understand encryption to benefit from it.
In enterprise software, secure-by-design thinking looks different but follows the same principle. A customer relationship management (CRM) system designed securely doesn't ship with default admin accounts using weak passwords. Instead, it forces administrators to create strong unique credentials during initial setup—won't let you proceed otherwise. It doesn't have optional encryption for sensitive data. Sensitive data is encrypted automatically, period. Authorization isn't something you configure; it's baked into how the application works, with least-privilege access enforced from the start. Attack surfaces that could be eliminated are simply removed from the product. Features that pose risks without clear business value don't exist. The architecture assumes attackers will try to break it and makes that as difficult as possible structurally, not through optional settings customers might miss.
Why This Distinction Suddenly Matters (Hint: Regulators and Lawyers)
For years, "secure by default" was the norm. Products shipped with security as configurable options. If customers got breached, vendors said "not our fault—you didn't configure security properly." That era is ending fast. Regulators worldwide are moving toward requiring secure-by-design as minimum standard. The European Union's Cyber Resilience Act, expected to take effect in 2024-2027, will require manufacturers to ensure products are secure by design throughout their lifecycle—not just ship with security features customers can optionally enable. Products failing to meet these standards won't be sold in EU markets. The United States isn't far behind. The Cybersecurity and Infrastructure Security Agency (CISA) released "Secure by Design" guidance in 2023, pushing software manufacturers to take responsibility for security rather than shifting burden to customers.
Why now? Because the consequences of insecure products have escalated beyond individual companies getting hacked. When a smart thermostat helps hackers breach a casino, that's embarrassing. When insecure medical devices put patient lives at risk, that's a public health crisis. When insecure industrial control systems can be weaponized to cause infrastructure damage, that's a national security threat. Regulators are responding to this reality by demanding manufacturers build security in, not bolt it on. Legal liability is shifting too. Product liability lawsuits increasingly target software vendors whose insecure products caused downstream breaches. The argument: if your product shipped with default credentials, inadequate authentication, or known vulnerabilities that you could have prevented during design, you're partially liable for resulting damages.
Insurance companies are getting involved as well. Cyber insurance policies increasingly exclude coverage for breaches caused by failure to change default credentials or enable basic security settings. Their position: if you didn't take minimal security precautions, you're not insured. This creates a cascade effect. Customers demand secure-by-design products because they can't get insurance otherwise. Vendors must adapt or lose market access. The market is forcing change even where regulation hasn't yet.
What Secure by Design Actually Looks Like (Beyond the Marketing)
Every software vendor now claims their products are "built with security in mind" or "designed for security." Marketing teams love these phrases. But genuine secure-by-design implementation shows specific characteristics anyone can verify. First: mandatory authentication without default credentials. The product won't run until administrators create unique credentials meeting complexity requirements. No "admin/password" to start with. Second: encryption of sensitive data isn't optional. Customer data, authentication tokens, and other sensitive information is encrypted at rest and in transit automatically, with no settings to configure. Third: least-privilege access is architectural. Users and system components get minimum necessary permissions, and privilege escalation requires explicit authentication and approval. You can't accidentally give someone admin rights.
Fourth: security updates are automatic or strongly enforced. The system checks for patches and either applies them automatically or nags persistently until administrators do. No ability to disable updates and run vulnerable software indefinitely. Fifth: attack surfaces are minimized by design. Unnecessary network ports are closed. Unused services are disabled or don't exist. Remote access requires multi-factor authentication. Features that add risk without clear business value simply aren't included. Sixth: security failures are logged and monitored by default. When authentication fails, access is denied, or unusual activity occurs, the system records it without requiring configuration of logging systems. These aren't optional features. They're how the product works fundamentally. Can't be disabled. Don't require security expertise to benefit from. Just work.
Three Questions to Ask Before Buying Software (That Vendors Hate)
When evaluating software products—whether you're buying enterprise applications, smart devices, or cloud services—ask these questions. Vendors hate them because they expose secure-by-default thinking masquerading as secure-by-design. Question one: "Does this product ship with default credentials, or does setup force creation of unique credentials?" If there's a default password, even if documentation tells you to change it, that's secure-by-default thinking. Question two: "What security features are optional versus automatic?" If the answer is "we provide encryption, but customers can enable it in settings," that's a red flag. Security should be automatic. Question three: "If I deploy this product with zero configuration beyond the minimum to make it functional, is it secure?" Honest answer for most products: no. They require extensive hardening, configuration, and ongoing maintenance to be secure. That's fine for sophisticated organizations with security teams. It's dangerous for everyone else.
Secure-by-design products work securely out of the box, requiring minimal configuration. The burden is on the manufacturer to build it right, not on you to configure it properly. As regulations tighten and liability increases, this distinction will separate viable products from liability nightmares. Choose accordingly.
AKATI Sekurity: Helping Organizations Build and Buy Secure Software
Whether you're developing software products or buying them, secure-by-design thinking matters. AKATI Sekurity's Cybersecurity Consulting services help software development organizations implement secure-by-design principles throughout product lifecycles. We review architecture designs, identify security flaws early when they're cheap to fix, and guide teams on building security into foundations rather than adding it afterward. Our Application Security services include secure architecture review, threat modeling during design phases, and secure coding standards development. For organizations purchasing software, our Security Posture Assessments include third-party software risk evaluation—analyzing whether vendors' security claims match reality and identifying products that pose unacceptable risks.
Our Penetration Testing services validate whether products marketed as "secure by design" actually resist attacks, or whether security is superficial. For ASEAN organizations preparing for evolving cybersecurity regulations in Singapore, Malaysia, Thailand, and other markets, we help align product security with emerging requirements. For US organizations facing pressure from CISA's Secure by Design initiative and potential future regulations, we provide guidance on meeting expected standards before they become mandatory.
Build security in, not on. Contact AKATI Sekurity at hello@akati.com for more information.
About the Author: This article was written by AKATI Sekurity's application security and product security specialists who help organizations develop secure software and evaluate security risks in third-party products across financial services, healthcare, technology, and manufacturing sectors in ASEAN and North America.
Related Services: Cybersecurity Consulting | Penetration Testing | Security Posture Assessment | Application Security
Key Terms Explained:
Secure by Design: Building security into product architecture from the beginning, making it intrinsic rather than optional
Secure by Default: Providing security features that customers must configure to be effective
Default Credentials: Pre-configured usernames and passwords that ship with products (major security risk)
Attack Surface: All possible ways an attacker could interact with and potentially compromise a system
Least Privilege: Security principle of giving users/systems only the minimum access needed
References:
CISA Secure by Design Initiative: https://www.cisa.gov/securebydesign
EU Cyber Resilience Act (Proposed Regulation)
OWASP Secure Product Design Guidelines
NIST Secure Software Development Framework (SSDF)
Tags: Secure by Design, Secure by Default, Product Security, Software Security, Secure Software Development, Application Security, IoT Security, Default Credentials, Security Architecture, CISA Secure by Design, Cyber Resilience Act, Software Security Malaysia, Product Security ASEAN
