When it comes to software development, it's important that security is incorporated from the outset, rather than being an afterthought at a later stage.
The Secure Software Development Lifecycle highlights the importance of embedding security practices throughout all stages of system development, spanning from the earliest concept to deployment and ongoing maintenance. At the center of this lifecycle are two critical yet frequently misunderstood design phases - high level design (HLD) and low-level design (LLD).
Although the terms originate in system engineering and security architecture, the logic behind them aligns closely with design practices. What security architects describe as HLD can often be compared to wireframes, and user journey models in design. Similarly, what is captured in LLD corresponds to production-ready visual design, interaction specifications and design systems.
In this article, we explore the differences between HLD and LLD within the SSDLC, focusing on how security assumptions made at the architectural level influence concrete UX/UI solutions at the implementation level.
High level design provides a macro-level blueprint for a software system, defining how its components interact, how data moves and how security considerations are integrated into the architecture. Within the SSDLC framework, the HLD stage is where key decisions regarding system boundaries, trust zones and security requirements are made, long before implementation details are considered.
At this stage, the focus is on what the system should achieve, rather than how it will achieve it.
|
System architecture |
The process involves identifying major modules, services, databases and APIs, as well as their interconnections and data flows. For instance, distinguishing between internal services, external integrations and third-party APIs helps to determine where security controls should be implemented. |
|
Data flow & classification |
This requires mapping how data moves across the system, determining sensitivity levels and identifying areas that require encryption or strict access controls. This step is essential for threat modelling, as it reveals potential attack surfaces. |
|
Threat modeling & security requirements |
At HLD, designers anticipate potential threats and define security objectives. These may include authentication and authorization strategies, encryption standards, logging and monitoring policies, and compliance requirements. |
It also involves considering user journeys and human-centered security. Decisions made at this stage affect how end users interact with the system and their potential for making errors. For example, assuming that all users will consistently use strong passwords without difficulty could result in risky workarounds if the system's user experience is not carefully designed. HLD must therefore consider the cognitive load and behavior of users, as well as technical security requirements.
In the context of the SSDLC, low level design involves translating high-level architectural decisions from HLD into concrete, detailed implementations. In the SSDLC, the focus is on how security and usability requirements are realized at system, application and user interface levels. While HLD defines what the system should do, LLD specifies exactly how it will be done, addressing technical, operational and human factors in minute detail.
|
Implementation of security controls |
Selecting specific technologies, protocols, and frameworks, for example, encryption algorithms, access control models and their enforcement at API and database levels, logging, monitoring, and alerting configurations to detect and respond to suspicious activities. |
|
Data validation & handling |
Precise mechanisms are designed to prevent injection attacks, improper input handling and sensitive data leaks. LLD ensures that all HLD assumptions are consistently enforced across modules. |
|
Authentication & authorisation details |
Translating HLD decisions into actual workflows and interface behaviors. For instance, if the HLD requires multi-factor authentication for high-value transactions, the LLD determines the MFA method, user interface patterns to guide and educate users during authentication, error handling, fallback mechanisms and session management, all with the aim of minimizing friction and risk. |
|
User-centered security implementation |
At LLD, we focus on making security controls usable, intuitive and resilient to human error. This involves designing clear error messages, preventing the accidental override of security measures, and ensuring that security mechanisms integrate seamlessly into workflows to avoid confusion and frustration. |
Security and usability are closely linked and can’t be treated as separate goals. If security measures become too complex or intrusive, users will often find ways to bypass them, introducing vulnerabilities. Conversely, if usability is prioritized over security, the system may be convenient but vulnerable. In the Secure Software Development Life Cycle, human-centered security must be integrated into both high level and low-level designs, ensuring that architectural decisions result in practical, user-friendly implementations.
During the HLD phase, teams must anticipate any potential risks to human-system interaction that could compromise security. For example, policies that require frequent password changes or excessive authentication prompts may appear robust in theory, but in practice they can result in user fatigue, password reuse or the unsafe storage of credentials. Similarly, enforcing multi-factor authentication for every action could create unnecessary friction in workflows where frequent verification is required. It is essential to recognize these risks early, while defining user journeys and threat models, in order to keep security requirements both effective and sustainable.
At the LLD stage, architectural concepts are transformed into practical, comprehensible and robust solutions. The focus then shifts to execution - authentication mechanisms must fulfil technical standards and be straightforward for users to understand and follow reliably. This involves using clear, plain language in prompts and providing straightforward error messages when authentication fails. It also involves offering fallback options, such as backup codes or alternative verification methods, to avoid lockouts. Rather than displaying the vague message 'Authentication failed', a well-designed system would specify whether the one-time password was incorrect, had expired or had been entered too late. Such specificity enables users to recover smoothly without compromising security.
The key to preventing such breakdowns lies in the continuous collaboration of design, security and development stakeholders. Joint reviews of HLD artefacts, such as architecture diagrams and user journey prototypes, and LLD specifications, like detailed workflows, API definitions and UI designs, help ensure that assumptions remain valid and feasible. Incorporating both usability and security testing throughout the lifecycle provides early feedback on alignment issues, enabling corrections before they reach production. Maintaining this alignment enables teams to deliver systems that are secure at the architectural level and trustworthy at the point of user interaction.
|
Aspect |
High level design |
Low level design |
|
Focus |
Macro-level system architecture, components, and interactions |
Micro-level implementation details of each component and workflow |
|
Scope |
Defines what the system should do and where controls are needed |
Specifies how controls and workflows are executed |
|
Security |
Identifies security requirements, trust boundaries, and threat models |
Implements specific mechanisms (e.g., encryption, access control, validation) |
|
Data handling |
Classifies data and defines flows between modules/services |
Applies concrete protections (e.g., TLS 1.3 for transport, AES-256 for storage) |
|
Authentication |
Determines when/where MFA or other controls are required |
Defines MFA method (TOTP, push, biometric), error handling, fallback, and session logic |
|
Human-centered security |
Anticipates risks at the human-system interface (e.g., password fatigue, workflow friction) |
Designs user-friendly, understandable security interactions and messages |
|
Design translation |
Comparable to wireframes/prototypes: user journeys, placement of controls |
Comparable to production-ready UI/design systems: finalized UI behaviors and visual specifications |
|
Deliverables |
Architecture diagrams, threat models, high-level security requirements |
API specifications, encryption standards, UI/UX patterns, error handling flows |
|
Risk if misaligned |
Unrealistic or incomplete assumptions can lead to unusable or insecure workflows |
Poor execution can undermine HLD intentions, causing user errors or weak security |
Incorporating security from the very beginning of software development is essential to building systems that are both robust and user-friendly. While HLD sets the strategic architectural framework and defines security requirements, LLD brings those principles to life through detailed, practical implementation focused on both technical robustness and user experience.
A successful SSDLC requires close collaboration between these two design phases to bridge the gap between what the system should do and how it should do it. By carefully aligning security assumptions with user behavior, teams can avoid common pitfalls such as overly intrusive controls or inconsistent enforcement, which can jeopardize both security and usability.
With human-centered security integrated thoughtfully at both the HLD and LLD stages, you can ensure that security controls are effective without imposing unnecessary burdens on users. The key to delivering secure software that users can trust and embrace is continuous cooperation across design, security, and development teams, supported by iterative testing and feedback.
Drive collaboration between design, development and security teams to align your security and usability goals and integrate continuous testing to identify issues early. Contact our experts to find out how we can help you build secure, user-friendly products!