Communication Security, Layer by Layer — TLS, Zero Trust & AuthN/AuthZ (US/EU)

Written: 2026-06 / Scope: the technology is jurisdiction-neutral; the regulatory part is US/EU-focused / last_updated: 2026-06-07 Changelog: 2026-06-07 first published as an international (US/EU) edition

About this series: this is the international edition of the second post in YATA-NODE's "how things work" series. Where the first post, How Enterprise Networks Work, covered "where to place the boxes (a map of placement)," this post gives a single overview of "at which layer, and with what, you protect the communication itself (a map of defense)." The map of placement and the map of defense are a pair; if the overall network picture matters to you, reading the first post first makes the layer story here easier to picture in three dimensions. For the rights and contract side, see the separate pre-ship rights checklist.

A few terms (for newcomers): the minimum vocabulary that recurs below.

• Layer: a way of viewing communication as a stack of role-by-role responsibilities — the bottom is electrical signals and cables, the top approaches the application and the act of logging in.
• OSI reference model: an international shared language that divides communication into seven layers (physical → data link → network → transport → session → presentation → application). This article adds "authentication and authorization" as an eighth layer and works with eight in total.
• Defense in depth: the idea of layering defenses across multiple layers so that if one defense is breached, the next still stands.
• Authentication / Authorization: authentication confirms "who the other party is"; authorization decides "what that party is allowed to do." They are different things (covered in detail at the eighth layer).
• TLS◆ (Transport Layer Security): encrypts traffic; what https:// relies on.
• VPN◆ (Virtual Private Network): an encrypted tunnel over a public network for secure remote access to a private network.
• WAF◆ (Web Application Firewall): detects and blocks web-app attacks (e.g., SQL injection).
• FDE◆ (Full-Disk Encryption): encrypts the entire disk so data stays unreadable if the device is lost or stolen.
• DB◆ (database): a system for storing, searching, and managing data.
• XSS◆ (Cross-Site Scripting): injecting malicious scripts into a web page so they run in a visitor's browser.

The tools of communication security come with so many names — TLS, IPsec, MFA, zero trust — that trying to memorize what each one is for tends to end in burnout. So this article lines everything up against a single lens: "at which layer, against which threat, and with what do you defend?" ① First we settle the "think in layers" mindset, ② then the lower three layers (path and reachability), ③ the middle-to-upper layers (the payload and the peer), ④ the eighth layer (who can do what), and ⑤ finally the cross-cutting themes that span layers — zero trust, quantum resistance, and regulation. Not by memorizing names but by "layer and role," let's build the foundation for spotting the gaps in your own defenses.

Think about communication security in layers

Communication is built from differently-roled processing stacked on top of one another — from the "physical" of electrical signals and cables, up to the stage where a login decides "who can do what." The model that organizes that stack in a language shared worldwide is the OSI reference model (seven layers). This article captures communication security in eight layers, adding authentication and authorization as an eighth layer on top. Authentication and authorization are not formally part of OSI's seven layers; because the design of identity and access has itself become important enough to count as a layer of its own, this article adds it to the map on its own. (Note: the colloquial "Layer 8 / L8" usually refers to the human user — people and politics; here we use the term differently, to mean authentication and authorization.)

The point of this map is that you don't protect everything with a single means; you layer defenses per layer (defense in depth). For example, even an attack that slips past the WAF (L7) meets the application's input validation, the database's least-privilege model, and the eighth layer's authorization check as the next gates. Each layer is designed on the premise that breaking any one of them does not collapse the whole.

That said, the boundaries between layers are not strict. TLS spans L4 through L7 in practice, and zero trust (discussed later) integrates L3 through the eighth layer. Read this table as a map arranged by which layer mainly holds the responsibility. If the three-zone map (internal LAN / DMZ / Internet) from the first post is "where to place the boxes," the eight layers here are "how to protect that traffic vertically." Overlay placement (horizontal) and layers (vertical) and the whole picture of your defenses starts to look three-dimensional.

The lower three layers (physical, data link, network) — protecting path and reachability

The bottom three layers (physical, data link, network) protect, roughly, "who can touch the wire" and "where the traffic arrives." As the stage before you encrypt the payload, their job is to keep the path and reachability healthy in the first place.

L1 physical layer — protecting devices and keys physically

The physical layer protects against physical access to devices, cables, and storage media. When you use the cloud, the data center's physical controls largely fall to the provider's area of responsibility (verify via SOC 2 or ISO 27001), while key management remains on your side. The core pieces are an HSM (Hardware Security Module), dedicated hardware for protecting keys; the device-side TPM (Trusted Platform Module); and FDE, which encrypts the whole disk. Using an HSM validated under the US cryptographic-module standard FIPS 140-3 (effective 2019; the CMVP stopped accepting new FIPS 140-2 submissions for validation in 2021, so new validations now target this revision) gives you assurance that the module's design and implementation passed third-party validation. How far keys are protected (e.g., whether they can be physically extracted) depends on the security level (Level 1–4) and the module's specification, so choose a product at the level your requirements call for. Confidential Computing, which encrypts even memory in use, is now available across the major clouds as well.

L2 data link layer — preventing eavesdropping and spoofing on the same premises

The data link layer prevents eavesdropping and spoofing within the same LAN. MACsec (IEEE 802.1AE), which encrypts the frame itself, can be used for things like data-center interconnects (dedicated-line services). 802.1X + EAP-TLS, which authenticates per port before connection, builds a certificate-based state where "only authorized endpoints get on the wire." On top of that, DAI (Dynamic ARP Inspection) and DHCP snooping counter on-premises attacks that abuse ARP or DHCP, and on wireless, WPA3 is the baseline defense.

L3 network layer — encrypting the path and controlling reachability

The network layer controls "where traffic arrives" and encrypts it along the path. The standard for protecting site-to-site and cloud connections with an encrypted tunnel is IPsec (RFC 4301) with IKEv2 (RFC 7296) for key exchange; the newer, faster WireGuard is also widespread. Permit/deny decisions are tightened to least privilege with firewalls and ACLs (access control lists).

Attacks that target the path itself live at this layer too. For DDoS, which paralyzes you with a flood of traffic, you prepare with BCP 38 (ingress filtering), which drops source-spoofed traffic at the entrance, and with cloud-side DDoS protection. For route hijacking, which seizes the Internet's routing information (BGP), RPKI (RFC 6480) plus ROA/ROV — which cryptographically validates a route's origin — is effective. Route hijacking is not a theoretical concern: it has actually happened, from YouTube being rendered unreachable in 2008 to traffic being diverted to a crypto-asset service in 2018.

The middle-to-upper layers (transport to application) — protecting the payload and the peer

What actually flows over the path — the "payload" and the "peer" — is protected by these middle-to-upper layers. The targets are mainly the three of eavesdropping, tampering, and impersonation, and the higher you climb, the closer you get to the meaning of the application and its data.

L4 transport layer — encrypting traffic end to end

The transport layer encrypts the payload end to end. What underpins the Web's https:// is TLS, and the current TLS 1.3 (RFC 8446, 2018) cleaned up past weaknesses and made faster, safer connections the standard. mTLS, where client and server confirm each other with certificates, is widely used for service-to-service communication (microservices). QUIC (RFC 9000) + HTTP/3, which integrates TLS 1.3 over UDP, is gaining ground too.

The important thing here is that you cannot simply say "use TLS and you're safe." Safety depends on the version and configuration. Old TLS 1.0/1.1 are recommended for deprecation (RFC 8996, 2021), and in the past, attacks such as POODLE and Heartbleed that exploit flaws in old versions or implementations have actually succeeded. These are examples of "how things were broken before," and the defense comes down to operations: standardize on newer versions, disable weak cipher suites, and automate certificate renewal.

L5 session layer — protecting the "state" after login

The session layer protects the state of "whose communication this is" after login. The aim of attacks is session hijacking or fixation (forcing someone to use another's session). The basics of defense are to make session IDs hard to guess, always re-issue them right after login, and correctly set Cookie attributes such as HttpOnly (unreadable from scripts), Secure (HTTPS only), SameSite (restricting cross-site sending), and __Host-. These interlock with the authentication and authorization discussed later.

L6 presentation layer — handling data representation and keys safely

The presentation layer makes the representation of data and the handling of keys safe. The representative example is JOSE, the family of standards (RFC 7515–7519, with operational guidance in RFC 8725) that includes the JWT (JSON Web Token), used for things like tokens that represent login state. The typical failures here are configurations that don't verify the signature (accepting alg=none) and algorithm confusion. The principle for tokens is to always verify the signature and keep them short-lived. Encryption of data at rest is also handled at this layer, using each cloud's key management service (KMS).

L7 application layer — protecting the payload of HTTP / APIs

The application layer protects the "payload" exchanged over HTTP and APIs, and it is where attacks concentrate most. Here a WAF (Web Application Firewall) blocks known attack patterns such as SQL injection and cross-site scripting (XSS). A representative rule set for WAFs is OWASP's Core Rule Set. The canonical list of threats to defend against in web apps is the OWASP Top 10: alongside the long-used 2021 edition, a 2025 edition that includes a new category for software supply chains (A03:2025 — Software Supply Chain Failures) has been released — note that standards are revised periodically, so check the OWASP primary source for the latest edition.

HTTP security headers, which tell the browser "how it should behave," matter too. Putting in HSTS (which forces communication to HTTPS at all times) and CSP (Content Security Policy, which restricts loadable scripts) by default can greatly reduce the attack surface. For APIs, an API Gateway acts as a gate for authentication, rate limiting, and schema validation.

What makes this layer frightening is that a weakness in a widely used component gets targeted all at once. Log4Shell (the vulnerability in the Java logging component Log4j) at the end of 2021 was the textbook case. That is exactly why it needs to be considered together with the dependency-library checks (pre-release checks) discussed later.

Layer 8, authentication & authorization — protecting "who can do what"

The final layer is authentication and authorization, which OSI's seven layers do not include. This article adds it to the map as a standalone eighth layer because, in modern communication, deciding "who can do what, under which conditions" has itself become a large design domain. (As noted above, this differs from the colloquial "Layer 8," which usually means the human user.)

First, let's separate two easily confused words. Authentication confirms "who the other party is", and authorization decides "what that confirmed party is allowed to do." Even someone who logged in correctly (authentication OK) must not be able to see other people's data (authorization is separate). When that distinction breaks down, you get incidents where login is rock-solid yet information leaks through an authorization gap.

Authentication — confirming "who the other party is"

Widely used for authentication federation in web and app contexts are OAuth and OIDC. OAuth (RFC 6749, 2012) is a mechanism by which an app is "delegated" authority on behalf of a user, and OIDC (OpenID Connect) layers identity verification (authentication) on top of it. A newer set of guidance distilling OAuth operational know-how is the BCP RFC 9700 (2025), which calls for PKCE — which prevents authorization-code interception — as mandatory for public clients (and recommended for confidential ones). For enterprise SSO, the XML-based SAML 2.0 (2005) remains mainstream even today.

What strengthens identity verification is multi-factor authentication (MFA). It combines two or more different factors from knowledge (password), possession (phone, key), and inherence (fingerprint, face) — a password plus a security question is not MFA, since both are knowledge. Time-based one-time passwords, TOTP (RFC 6238), are standard, but OTP over SMS is positioned as a "RESTRICTED" authenticator in NIST's Digital Identity Guidelines (SP 800-63B) because of risks such as SIM hijacking (SIM swapping) (this treatment has continued since Revision 3 and is maintained in Revision 4, finalized in 2025). A more phishing-resistant approach is FIDO2 / WebAuthn (W3C, Level 2 in 2021), where keys are bound to the domain so credentials are never handed to a fake site. Passkeys, usable across multiple devices, are also built on this WebAuthn foundation.

Authorization — deciding "what is allowed"

Authorization is the design of how far a confirmed party is allowed to go. Here are the representative models, from simplest up:

• RBAC (role-based): bundles permissions into roles such as "admin" or "general." Often sufficient on its own.
• ABAC (attribute-based): decides dynamically by attributes such as department, time of day, or device state.
• ReBAC (relationship-based): decides by a relationship graph like "who owns this file" (Google's Zanzibar and the OSS OpenFGA are representative).
• PBAC (policy-based): separates authorization rules from code and makes them testable in a dedicated engine (OPA, Cedar).

A particularly common incident in APIs is BOLA (Broken Object Level Authorization), where rewriting an ID in the URL lets you fetch someone else's data. It tops OWASP's API Security Top 10 and is the textbook case of "authentication passes but authorization is missing." This is where the importance of designing authentication and authorization as separate gates shows up.

Protecting credentials "on the wire"

The reason the eighth layer is part of communication security is that credentials themselves travel over the wire and can be stolen. Long-lived refresh tokens should, as a baseline, be swapped for a new one each time they're used, and all be revoked together once reuse of an old one is detected (rotation + reuse detection). Further, as mechanisms that make a stolen token hard to use, there is DPoP (RFC 9449), which binds a token to the client's key, and mTLS-bound tokens (RFC 8705).

Where this differs from the first post

The first post, How Enterprise Networks Work, also covered AD (Active Directory) and SSO + MFA. But its theme there was "where to place those boxes inside the company, and with what policy" (placement and policy). The eighth layer here covers what comes after that: "what threats arrive over the wire, and how to verify and protect credentials" (protocols and mechanisms). Read the placement story (first post) and the defense story (this post) together, and the whole picture of authentication and authorization connects up.

Cross-cutting themes and the regulatory drivers by jurisdiction

So far we've looked at defenses layer by layer, but there are three themes that take effect across layers: zero trust, quantum resistance, and regulation.

Zero trust — the "don't trust by location" mindset (spanning layers)

Zero trust is a design philosophy that drops the location-based premise of "trust it because it's on the internal network" and instead verifies identity, device state, and context on every access. Its technical foundation is NIST SP 800-207 (2020), which separates the part that makes decisions (the PDP) from the part that actually permits or blocks traffic (the PEP). The move from VPN to ZTNA touched on in the first post applies this idea to network connectivity.

What to keep in mind is that zero trust is not a mechanism where "deploy it and risk goes to zero." Rather, it is a realistic design that "by not fixing trust in place, limits the damage when you are breached." It only works when combined with the eighth layer's continuous verification (the authentication and authorization in this post), rather than granting broad access on a single authentication. Avoid treating it as a cure-all; the practical move is to decide, in stages, which of your layers to apply it from first.

Quantum resistance (PQC) — a migration to prepare for over years

Out of concern that a quantum computer could one day break today's public-key cryptography (such as RSA), preparation for migrating to post-quantum cryptography (PQC) has begun. The US NIST finalized its standard algorithms (FIPS 203/204/205) in 2024. As for the migration deadline, NIST has indicated a direction of "deprecating legacy algorithms around 2030 and disallowing them around 2035," but this is still a draft-stage outlook, not finalized. You don't need to migrate everything right now, but designing so cryptography can be swapped out later (crypto-agility) makes the future migration easier.

Regulation as a driver — United States

Technical standards may be shared worldwide, but what drives "by when, and who must adopt" is each jurisdiction's regulation and procurement conditions. In the United States, the dominant pattern is to drive adoption through executive orders and federal procurement layered on top of NIST's technical standards (such as SP 800-207 and SP 800-63B).

The starting point was Executive Order 14028 (May 12, 2021), which directed federal agencies toward zero trust, MFA, encryption in transit and at rest, and SBOMs. Operationalizing it, OMB Memorandum M-22-09 (January 26, 2022) required federal civilian agencies (FCEB) to meet specific zero-trust goals by the end of FY2024 (a deadline now passed), aligned with CISA's Zero Trust Maturity Model v2.0 (April 2023). For cloud, FedRAMP authorizes services for government use — analogous to Japan's ISMAP — and FedRAMP 20x (Phase One announced May 30, 2025) is moving the program toward automation. On post-quantum migration, CNSA 2.0 sets timelines for national-security systems (software/firmware signing around 2030, broader systems around 2033).

One caution: the executive-order layer is in flux with changes of administration. EO 14144 (January 16, 2025) built on EO 14028, adding measures in areas such as PQC and digital identity, and was itself later amended by EO 14306 (June 6, 2025). Treat the specific dates and obligations as a snapshot, and confirm the current text in the Federal Register before relying on it.

Regulation as a driver — European Union

Where the US leans on executive orders and procurement, the EU's distinctive feature is driving adoption through EU-level legislation — directly applicable regulations (CRA, DORA, GDPR) alongside directives that member states transpose into national law (NIS2). The backbone is the NIS2 Directive (Directive (EU) 2022/2555), whose national-transposition deadline was October 17, 2024. It requires essential and important entities to implement security measures (Article 21 explicitly includes policies on cryptography and encryption) and sets staged incident reporting under Article 23 (an early warning within 24 hours, a notification within 72 hours, and a final report within one month). In practice, transposition has been uneven — as of 2025 a number of member states had not completed it — so confirm the situation in your target country.

Other instruments stack on top. The Cyber Resilience Act (Regulation (EU) 2024/2847; in force December 10, 2024) places product-security and vulnerability-handling obligations on manufacturers of products with digital elements, with the main obligations applying from December 11, 2027 (though the reporting obligations under Article 14 apply earlier, from September 11, 2026). GDPR Article 32 requires appropriate security of processing — pseudonymization and encryption among them — backed by fines under Article 83(4) of up to €10 million or 2% of global annual turnover (Article 32 sits among the controller/processor obligations in Articles 25–39; the higher €20 million / 4% tier under Article 83(5) is for other infringements, such as the basic principles). eIDAS 2.0 (Regulation (EU) 2024/1183) drives digital-identity wallets, and DORA (Regulation (EU) 2022/2554; applying from January 17, 2025) sets ICT-risk rules for financial entities as a lex specialis to NIS2.

For Japan's drivers (CRYPTREC, ISMAP, and the active-cyber-defense law) and how they compare, see the Japanese edition, read against your own region.

Wrap-up

Communication security came down to layering defenses across eight layers, from the physical layer to authentication and authorization. The names of the means may be many, but rearrange them by "at which layer, against which threat, and with what do you defend" and you get a map for finding the gaps in your own defenses. To close, here is a checklist you can use as-is (copy and paste it).

[At project planning]
□ Decide your data classification (public / internal / confidential). Encryption requirements and authorization granularity derive from this.
□ Lock down the eighth layer (authentication & authorization) first (identity via OIDC + MFA, WebAuthn if possible / authorization on RBAC as the baseline, ABAC・ReBAC where needed / tokens with rotation + reuse detection).
□ Standardize L4 TLS on 1.3, disable old versions and weak ciphers, and automate certificate renewal.
□ Put the L7 security-header defaults in place (HSTS / CSP / __Host- cookies).
□ Configure L3 with least privilege and minimize the endpoints you expose.
□ Prefer managed services for L1–L2; consider MACsec / 802.1X when you run your own LAN.
□ Have a staged plan for which layer to apply zero trust from, and design so cryptography can be swapped out later.

[Before release / in operation]
□ Bring High / Critical findings to zero in a dependency vulnerability scan (SCA).
□ Enable the WAF and API rate limiting.
□ Test for authorization gaps (can someone fetch another person's data with another ID — i.e., BOLA?).
□ Scan for secrets (keys, passwords) accidentally committed to code.
□ Take inventory of identities and permissions and remove excessive privileges (least privilege).
□ Aggregate and monitor logs (identity platform / WAF / firewall / proxy).

Related posts: How Enterprise Networks Work / Pre-ship rights checklist

References

Last checked: 2026-06-07 / Jurisdiction scope: technical standards are jurisdiction-neutral. The regulatory part of this article is US/EU-focused (Japan's frameworks are covered in the Japanese edition).

Zero trust, authentication & authorization — technical standards (NIST / W3C)

• NIST SP 800-207 — Zero Trust Architecture (2020-08)
• NIST SP 800-63B — Digital Identity Guidelines (Authentication)
• W3C Web Authentication (WebAuthn) Level 2 (2021-04)
• NIST FIPS 203 / 204 / 205 — Post-Quantum Cryptography Standards (2024-08)

Communication encryption & routing (IETF RFC)

• RFC 8446 — TLS 1.3 (2018) / RFC 8996 — Deprecating TLS 1.0/1.1 (2021)
• RFC 9000 — QUIC (2021)
• RFC 4301 — IPsec (2005) / RFC 7296 — IKEv2 (2014)
• RFC 6480 — RPKI (2012)

Authentication, authorization & tokens (IETF RFC)

• RFC 6749 — OAuth 2.0 (2012) / RFC 9700 — OAuth 2.0 Security BCP (2025)
• RFC 7636 — PKCE (2015) / RFC 6238 — TOTP (2011)
• RFC 7519 — JWT (2015) / RFC 8725 — JWT BCP (2020)
• RFC 9449 — DPoP (2023) / RFC 8705 — OAuth mTLS (2020)

Web apps / API (OWASP)

• OWASP Top 10 / OWASP API Security Top 10

US policy & programs

• Executive Order 14028 — Improving the Nation's Cybersecurity (2021-05-12)
• OMB M-22-09 — Federal Zero Trust Strategy (2022-01-26) / CISA Zero Trust Maturity Model
• FedRAMP / NSA CNSA 2.0

EU policy & programs (EUR-Lex)

• NIS2 Directive — Directive (EU) 2022/2555 / Cyber Resilience Act — Regulation (EU) 2024/2847
• GDPR Art. 32 — Regulation (EU) 2016/679 / eIDAS 2.0 — Regulation (EU) 2024/1183 / DORA — Regulation (EU) 2022/2554

Each standard, service name, and regulation changes with rebrands and amendments. This article is a planning-stage overview; when making implementation decisions, confirm the latest specifications, scope, and deadlines against the primary sources above. RFC and standard numbers and publication years can be checked at the primary links above, but the enforcement status of each regulation is fluid — especially the US executive-order layer, which shifts with changes of administration — so confirm the current state in official sources at the time you read this.

About the author

I have over 20 years of hands-on electrical and software development experience — from control engineering at a major electronics manufacturer — plus roughly 10 years of personal development. Across hardware and software, and across the enterprise and the individual, I write starting from the "you'll be at risk if you don't know this" fundamentals, and I plan to move into practical uses of AI over time. More at About this blog.