Cy Logic Insights

Zero Trust is Not Just for Enterprises: A Practical Roadmap for SMBs

Zero Trust principles from NIST SP 800-207, simplified for small and medium businesses: identity, devices, segmentation, least privilege and continuous verification.

The traditional security model resembles a castle: if the outer wall (firewall) is solid, everything inside is considered safe. However, today employees connect from home, applications run in the cloud, and a significant portion of attacks start "from the inside" using a compromised user account. The Zero Trust approach reverses this assumption: no user, device, or network is trusted by default due to its location; every access request is verified and limited with the principle of least privilege.

Source: NIST SP 800-207

The US National Institute of Standards and Technology's SP 800-207 document defines the core principles of Zero Trust architecture: all data sources and services are treated as resources, all communication is secured regardless of network location, access is granted on a per-session basis with dynamic policy, and the state of assets is continuously monitored. These principles are product-agnostic and can be implemented using tools that SMBs already have.

Step 1: Identity at the Center

The foundation of Zero Trust is strong identity authentication. The minimum viable set:

  • Multi-factor authentication (MFA) on all corporate accounts; application-based or hardware keys are preferred over SMS.
  • Reducing the number of accounts via Single Sign-On (SSO); access for a departed employee must be revokable from a single place.
  • Elimination of shared accounts; a "common admin password" is incompatible with Zero Trust.

Step 2: Device Health

Having a correct account is not enough; the connecting device must also be known and up to date. For small teams, the practical path is maintaining an inventory of corporate devices, enforcing disk encryption and automatic updates, and restricting access from personal devices to specific applications only.

Step 3: Network Segmentation

A single flat network means the compromise of one device leads to the compromise of the entire network. Servers, user devices, guest networks, and IoT devices (cameras, printers, in-room televisions) must be in separate segments, and traffic between segments should be limited only to necessary ports. Example: in-room IPTV devices only access the streaming server, never the accounting server.

# Example (conceptual) segment rule — only necessary traffic
# source segment      destination segment     port     decision
kullanici_lan      -> uygulama_sunucu   443      allow
kullanici_lan      -> veritabani        5432     deny
uygulama_sunucu    -> veritabani        5432     allow
misafir_wifi       -> *                 *        deny (internet only)

Step 4: Least Privilege and Application Layer

Zero Trust is not just a network issue; it also applies inside the application. Every user should see only the data required for their job, and this rule should be enforced at the database level (such as PostgreSQL Row Level Security). Administrator privileges should not be continuous; they must be granted on-demand and for a limited time.

Zero Trust is not a product, but a habit of decision-making: ensuring the system asks the question with every new access request: "is it truly necessary for this person, from this device, to access this data at this moment?"

Step 5: Visibility and Logging

Centralizing identity provider, server, and application logs ensures that unusual behavior (midnight login from a different country, bulk data downloading) can be noticed. The retention period and access authorization for logs must be defined; logs are data too.

Step 6: Rethink Remote Access

Classic VPN brings the user inside the network; in the Zero Trust approach, the user reaches only the application they need, after identity and device verification. For small teams, application-based access intermediaries (identity-aware proxies) make this transition possible.

Suggested Implementation Order

  1. MFA and elimination of shared accounts (lowest cost, highest impact).
  2. Device inventory and forced updates.
  3. Separation of guest and IoT networks.
  4. In-app least privilege and audit logging.
  5. Making remote access application-based.

In-App Zero Trust: Example with PostgreSQL

As important as network-level segmentation is evaluating every application request with the user's identity and scope. PostgreSQL Row Level Security brings this principle to the data layer: no matter what query the client sends, the policy condition is applied.

-- Example: branch-based access (conceptual)
alter table orders enable row level security;

create policy orders_by_branch on orders
  for select using (branch_id = any (current_user_branches()));

-- Even the admin does not see everything; "all branches" permission is given via a separate role and for a limited time.

The beauty of this approach is that a bug in the application code (a forgotten where condition) does not turn into a data leak.

Time-Bound Administrator Privileges

Continuous admin rights are the most frequently violated principle of Zero Trust. Practical model: a separate account for administrative tasks, the privilege of this account is opened on demand and for a specific duration (e.g., one hour), the justification for opening is logged, and it automatically closes at the end of the duration. In small teams, this can be set up with a simple approval workflow and scheduled task; it does not require a complex privileged access management product.

Vendor and External Support Access

Software vendors, accounting consultants, and external support teams access systems; these accesses are often the weakest link. Rules: a separate account for each external individual (no shared "support" account), MFA mandatory, access restricted only to the relevant application and time-bound, all sessions logged. Closing access when the contract ends must be a checklist item.

Phased Implementation: An Example 90-Day Plan (Fictional)

PeriodStepOutput First MonthMFA, closing shared accounts, device inventoryAccount list, device list Second MonthSeparation of guest and IoT networks, external-facing service inventorySegment schema, closed services Third MonthIn-app RLS, central logging, time-bound admin privilegePolicy tests, alert rules

This schedule is an example; it varies depending on the size and current state of the business. The important thing is the order: identity first, then network, then application.

Common Misconceptions

    "Zero Trust means buying a product." No; it is a set of principles starting with existing tools. Products make some steps easier, but they do not substitute the principle. "If we have a VPN, we are safe." VPN brings the user inside the network; Zero Trust asks for the exact opposite. "We are small, we won't be targeted." Automated attacks do not choose targets; they find open ports and weak passwords. "Once set up, it's done." Zero Trust is a process reapplied with every new application and every new employee.

The access control, network security, and log management headings in the ISO/IEC 27001:2022 control set largely overlap with these steps; meaning the Zero Trust journey also paves the way if there is a future certification goal. Cy Logic's cybersecurity service implements this approach from the design phase in software and infrastructure projects.