What Does VTY Mean?
On This Page
Quick Definition
VTY stands for Virtual Teletype. It is a virtual terminal connection that lets you manage a Cisco router or switch from a remote computer. Instead of plugging a cable directly into the device, you connect over a network using protocols like Telnet or SSH. VTY lines are like virtual doors that multiple administrators can use to access the device's command-line interface remotely.
Commonly Confused With
The console line (line console 0) is a physical port on the device used for direct, out-of-band management. It requires a serial cable and local physical access. VTY lines are virtual and used for remote, in-band management over a network. Console access does not require an IP address; VTY access requires a functioning IP stack on the device.
You connect a laptop to the console port of a router to set an initial IP address. Later, you use SSH (VTY) from that laptop to configure the router without cables.
The AUX (Auxiliary) port is another physical serial port on some Cisco devices, typically used for modem-based remote access. It is slower and rarely used today. VTY lines are faster, support multiple protocols (Telnet/SSH), and are the standard for modern remote management. AUX is a physical interface; VTY is logical.
A router in a remote oil rig might use an AUX port with a dial-up modem for backup management. The primary remote access uses VTY over a satellite link.
TTY (Teletype) is a generic term for terminal lines used in older operating systems. In Cisco IOS, TTY lines refer to physical asynchronous serial lines, often on access servers. VTY is a virtualized version of TTY that works over network protocols. The configuration syntax is similar, but VTY lines do not require a physical serial port.
An old Cisco 2500 access server had 16 TTY lines for modem connections. A modern router uses VTY lines for SSH connections instead.
The management interface is a dedicated physical or logical port (like a loopback) that has an IP address and is used as the target for VTY connections. The VTY lines themselves are not interfaces; they are the virtual connection points. Confusing the two leads to the mistaken belief that VTY lines have their own IP addresses.
You assign IP 10.0.0.1 to loopback0. You SSH to 10.0.0.1 — the VTY line is the channel, loopback0 is the doorbell.
Must Know for Exams
VTY lines are a core topic in the Cisco CCNA (200-301) exam. The official exam blueprint includes objectives related to remote access, SSH configuration, and network device security — all of which revolve around VTY understanding. You will encounter questions that ask you to configure VTY lines, troubleshoot why remote access is failing, or identify security weaknesses in a given configuration.
Typical exam objectives covered include: configuring SSH on a device (which requires VTY transport input set to SSH), applying ACLs to VTY lines with the access-class command, setting login authentication methods (local or AAA), and setting exec-timeout and session-limit parameters. You must also understand the difference between console, AUX, and VTY lines, and when each is used.
In the exam, you might see a multiple-choice question like: "Which configuration is required to allow SSH access to a Cisco router?" The correct answer includes 'transport input ssh' under VTY line configuration. A trap answer might say 'transport input telnet' or omit the VTY lines entirely. You also need to know that to use SSH, you must first generate RSA keys with the crypto key generate rsa command, and that VTY lines must be configured with login local and a username/password.
Another common question type involves troubleshooting — a candidate cannot SSH to a router, and the exhibit shows VTY lines with 'transport input none' or 'login authentication default' pointing to a missing AAA server. You must identify that the VTY lines are misconfigured. Scenario-based questions may describe a network where only certain users should have access, and you must apply an ACL to the VTY lines. In simulation labs (the CCNA still uses some simlets), you may be asked to directly configure VTY lines as part of a larger configuration task.
The exam also tests your understanding of VTY line numbering and default settings. For example, you should know that a Cisco 2960 switch running IOS 15 supports 16 VTY lines (0-15), and that if you only configure lines 0-4, lines 5-15 remain with default (often insecure) settings. This is a classic exam trap. The exam expects you to apply a consistent configuration to all VTY lines, often using the line vty 0 15 command.
In summary, VTY configuration is not just a peripheral topic — it is a must-know area for CCNA success. You should practice configuring VTY lines in a lab environment until the commands become second nature.
Simple Meaning
Think of a Cisco router or switch as a secure building with only one main entrance — the console port — where you must be physically present to enter. That is inconvenient if the device is in a basement server room or a data center across the country. VTY lines are like adding several remote, secure side doors to the building. Each VTY line is a virtual connection point that allows a network administrator to log in from their desk, or even from home, using a network connection. These virtual doors are numbered, typically from 0 to 4 or 0 to 15 on newer devices, meaning you can have up to 16 remote administrators connected at the same time. When you use a program like PuTTY or a terminal emulator to Telnet or SSH into the device's IP address, you are actually connecting to one of these VTY lines. The device sees the incoming connection and assigns it to the next available VTY line. Without VTY lines, every configuration change would require someone to physically travel to the device with a console cable. In large networks with dozens or hundreds of devices, that would be impossible. VTY lines also support security features. You can restrict which IP addresses are allowed to connect, enforce strong passwords, and require encryption through SSH. This makes remote management safe and practical. In short, VTY lines are the standard way network engineers interact with Cisco equipment after initial setup, making them one of the most fundamental concepts in network administration.
One helpful analogy is a multi-line phone system at a busy office. The office has a main switchboard (the console port) but also several direct inward dialing (DID) lines — each is a virtual path for an incoming call. Similarly, VTY lines are the numbered channels through which remote management sessions enter the device. When you dial (connect) to the office number (the device IP), the phone system routes you to an available line. The device treats each VTY line as a separate terminal session, so multiple administrators can work simultaneously without interfering with each other.
Full Technical Definition
VTY (Virtual Teletype) lines are logical interfaces on Cisco IOS devices that provide remote access to the command-line interface (CLI) using transport protocols such as Telnet (TCP port 23) or SSH (TCP port 22). They are defined under the line configuration mode and are independent of physical ports. VTY lines are numbered sequentially, with older Cisco IOS releases supporting lines 0 through 4 (five total virtual connections), while modern IOS versions and Cisco IOS XE support lines 0 through 15 (sixteen simultaneous sessions). Each VTY line can be individually configured with authentication methods, access control lists (ACLs), timeout settings, and protocol restrictions.
When a remote client initiates a Telnet or SSH connection to the device's IP address, the IOS operating system intercepts the incoming TCP connection and maps it to the first available VTY line that matches the incoming transport protocol. The device does not track which physical interface the connection arrived on — it only sees the TCP session targeting the device's management IP (usually a loopback or VLAN interface). Once mapped, the VTY line spawns a virtual terminal session that presents the CLI prompt. The user is then authenticated through the configured method, which can be local username/password, RADIUS, TACACS+, or a simple password (though the latter is deprecated for security reasons).
VTY lines support several configuration parameters that are essential for secure and reliable network management. The "transport input" command dictates which protocols are allowed on each line — commonly "ssh" or "telnet ssh" but not just "telnet" alone in modern implementations. The "access-class" command applies an ACL to restrict source IP addresses that can initiate a VTY session. The "exec-timeout" command sets an idle timeout (default is 10 minutes) after which the session is terminated. The "session-limit" parameter can control the maximum number of VTY sessions from a single source. Additionally, VTY lines can be configured with "login local" to require individual credentials, or "login authentication" for AAA-based authentication.
From a protocol standpoint, VTY sessions use the same terminal semantics as a direct console connection. They transmit ASCII characters over a network stream, and the IOS CLI interprets keystrokes the same way. However, VTY lines do not transmit console-specific signals like break sequences unless special characters are configured. When SSH is used, all traffic is encrypted, including passwords and configuration commands, which is critical for compliance with security standards such as PCI-DSS and HIPAA. Telnet, by contrast, sends everything in plaintext and is generally avoided in production environments.
In real IT implementation, network engineers configure VTY lines as part of the initial device setup. A typical secure configuration includes: enabling SSH, generating RSA keys, creating local usernames with encrypted passwords, and applying an ACL to the VTY lines limiting access to management subnets. The VTY lines themselves do not have IP addresses — they are not interfaces. They simply provide the virtual connection point. The IP address used for remote access belongs to one of the device's Layer 3 interfaces (e.g., VLAN 1, GigabitEthernet0/0, or a loopback interface). If that interface is unreachable, the VTY lines are also unreachable. Therefore, maintaining a management interface (often a loopback) that is always reachable through routing protocols is a best practice to ensure VTY access remains available even if a physical interface goes down.
VTY lines also play a role in out-of-band management. In many data centers, network devices have a dedicated management port (like the MGMT port on Cisco Catalyst switches) that is in a separate VRF (Virtual Routing and Forwarding) context. In such cases, the VTY lines are still used, but the device's management routing table determines which IP address is used for incoming connections. This separation allows management traffic to be isolated from production traffic, improving security and stability.
Real-Life Example
Imagine you are the facilities manager for a large office building that has 16 separate security guard stations, each with its own desk, chair, and intercom. However, the building only has one main entrance with a receptionist. If you want to talk to a guard on the third floor, you have to walk to the third floor. That is how a Cisco device works with only a console port — you must be physically present.
Now, suppose you install 16 video intercom screens at your desk — each one can connect to a different guard station. When you press a button for station 3, you are instantly connected to the guard at that station. You can talk, give instructions, and monitor activities without ever leaving your chair. The video intercom system gives you 16 virtual connections to the remote guard stations. That is exactly what VTY lines do for network administrators. Each VTY line is like one of those video intercom channels.
When you SSH into a router, the device assigns your session to the first free VTY line — say line 2 — and you get a CLI prompt. Meanwhile, a colleague in another office can SSH to the same router and be assigned VTY line 3. You are both working on the same device remotely, just like two managers talking to different guards. If all 16 VTY lines are in use, any new connection attempt is refused (like when you push the button for station 7 but all intercom channels are busy).
Now add security. You can configure the intercom system so that only calls from your office phone are accepted — that is an ACL on the VTY lines. You can also require a PIN for each guard to verify who they are — that is SSH with usernames and passwords. If you want to prevent anyone from listening to your conversation, you use an encrypted intercom — that is SSH instead of Telnet. This analogy maps directly to how VTY lines work: they are virtual channels that allow remote, secure, and simultaneous access to the device's management interface.
Why This Term Matters
VTY lines are the foundation of remote network device management. In modern IT environments, network devices are rarely accessed directly via console cable unless during initial deployment or disaster recovery. The vast majority of configuration changes, troubleshooting, and monitoring are performed over the network using VTY connections. This makes VTY configuration a critical security control point. A misconfigured VTY line can expose the entire network to unauthorized access.
From a practical standpoint, understanding VTY lines helps network engineers design secure management access policies. For example, you can restrict VTY access to only trusted management subnets using ACLs, enforce SSH version 2 for encryption, and set idle timeouts to prevent unauthorized use of abandoned sessions. Without these configurations, an attacker who gains access to a device's IP address could attempt to brute-force Telnet credentials or exploit weak authentication.
VTY lines also affect network availability. If all VTY lines are consumed by legitimate or malicious sessions, the device becomes unreachable for remote management until a session times out or is manually cleared. This is known as VTY exhaustion, and it can be mitigated by limiting the number of sessions per source IP and setting appropriate timeouts. In production networks, monitoring VTY usage through SNMP or syslog is a common practice.
Furthermore, VTY lines are tied to the device's management interface. If that interface goes down due to a routing issue or interface failure, remote access is lost. Therefore, using a loopback interface as the management IP, combined with redundant routing paths, ensures VTY reachability even during link failures. In summary, VTY lines are not just a feature — they are a fundamental part of operational security and reliability for any network professional.
How It Appears in Exam Questions
VTY questions appear in the CCNA exam in several distinct patterns. The first is direct configuration: the question provides a partial configuration and asks you to complete it to allow remote SSH access. For example, you might be asked to place the 'transport input ssh' command under the correct line configuration mode. You need to know that 'transport input' is set under 'line vty 0 15'. A variant may ask for the command to restrict access to only the 192.168.1.0/24 subnet, which is 'access-class 10 in' applied under the VTY lines, with 'access-list 10 permit 192.168.1.0 0.0.0.255' previously configured.
The second pattern is scenario-based troubleshooting. A network administrator reports that they cannot SSH to a router but can ping it. The exhibit shows the running-config of the router. You must identify the misconfiguration. Common pitfalls include: VTY lines have 'transport input none' (which denies all protocols), VTY lines have 'login authentication default' but no AAA server is reachable, or the VTY lines have 'password' set but no 'login' command. The question may also show that the username is missing or that RSA keys are not generated. In such questions, you must systematically check each piece: SSH prerequisite (RSA keys), VTY transport, login method, and authentication credentials.
The third pattern is conceptual multiple-choice. These questions ask you to choose the correct statement about VTY lines. For example: "Which of the following is true about VTY lines?" Options might include "They are used for out-of-band management" (false — that is console), "They can only be used with Telnet" (false), "They require a username and password" (true if configured with login local), or "They are numbered 0 through 15 on modern devices" (true). Another common conceptual question: "What is the default number of VTY lines on a Cisco 4331 router?" Answer: 16.
The fourth pattern is policy-based. A question might describe a security policy requiring that all remote management be encrypted, and the auditor finds Telnet is still enabled. You must select the configuration to disable Telnet and allow only SSH. The correct answer involves both 'transport input ssh' under VTY lines and the 'ip ssh version 2' command. A trap answer may suggest 'no transport input telnet' is sufficient (it does not prevent Telnet by itself — you must set transport input to only ssh).
The fifth pattern is integration with ACLs. You might see a configuration with an ACL applied to VTY lines, and you need to interpret which hosts are allowed remote access. For instance, 'access-class 5 in' applied to VTY with ACL 5 permitting 10.0.0.0 0.0.0.255 — you must conclude that only devices in the 10.0.0.0/24 network can initiate VTY sessions.
To excel in these question types, practice configuring VTY lines in Packet Tracer or GNS3. Focus on the interplay between VTY configuration, ACLs, AAA, and SSH prerequisites.
Practise VTY Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a network administrator for a company with five branch offices. Each branch has one Cisco 2921 router connecting the branch LAN to the WAN. You are sitting at your desk in the headquarters in New York, and you need to change the routing protocol configuration on the router in Chicago. You cannot physically travel to Chicago, so you must connect remotely.
You have already configured SSH and VTY lines on the Chicago router during initial deployment. Your management station in New York has an IP address of 10.1.1.100. The Chicago router's management interface (GigabitEthernet0/0) has an IP of 192.168.5.1. You open your SSH client (e.g., PuTTY) and initiate a connection to 192.168.5.1. The Chicago router receives the TCP SYN on port 22 and checks if any VTY line is available. Since no other sessions are active, VTY line 0 is free. The router allocates line 0 to your session.
The VTY line configuration on the Chicago router includes: 'transport input ssh' (so Telnet is blocked), 'login local' (requires a local username/password), and 'exec-timeout 5 0' (idle timeout of 5 minutes). You are prompted for a username and password, which you correctly enter. The router authenticates you against the local database, and you are now at the privileged EXEC prompt. You configure OSPF as needed, save the configuration, and exit.
Later that day, two other engineers from Denver and London also need to work on the same router simultaneously. They both SSH in, and the router assigns them VTY lines 1 and 2. Another engineer in Tokyo tries to connect but gets a 'connection refused' message because all 16 VTY lines are not full yet — wait, actually the router has lines 0-15, so three sessions should be fine. But if 16 simultaneous sessions were active, the 17th engineer would be refused, which is what the question might present as a 'VTY line exhaustion' scenario.
Now imagine one of the engineers leaves their session idle for 10 minutes. The exec-timeout triggers, and the VTY line is freed. The Tokyo engineer tries again and this time succeeds. This scenario illustrates the dynamic allocation of VTY lines and the importance of timeouts to prevent exhaustion.
Common Mistakes
Assuming VTY lines are physical interfaces like Ethernet ports.
VTY lines are logical endpoints for remote terminal sessions, not physical hardware. They exist only in software and are used to manage the device. Treating them as physical interfaces leads to confusion about IP address assignment and cable connections.
Remember that VTY lines are like virtual seats at a terminal. They do not have MAC addresses or IP addresses themselves. Instead, they rely on the device's management IP for incoming connections.
Configuring 'transport input telnet' only because SSH seems complex.
Telnet transmits all data, including passwords, in plaintext. In a production network, this is a massive security risk. The CCNA exam emphasizes secure management practices, so using Telnet alone or without SSH is considered a security violation.
Always configure 'transport input ssh' or 'transport input telnet ssh' (if backward compatibility is required). Generate RSA keys and use SSH version 2 for encryption.
Forgetting to configure 'login local' on VTY lines after setting up local usernames.
Without 'login local', the VTY lines will use the default 'login' method which checks the enable password. If no enable password is set, the router will prompt for a password that does not exist, effectively locking out all remote administrators.
After creating usernames with 'username admin secret cisco', apply 'login local' under the VTY line configuration to force the router to use the local database for authentication.
Applying an access-class ACL to VTY lines but forgetting to apply it in the correct direction.
The 'access-class' command with the 'in' keyword filters incoming connections to the VTY lines. If you omit 'in' or use 'out', the behavior is different or does not filter at all. For example, 'access-class 10 out' would filter traffic that the device sends through the VTY session, not the incoming connections.
Always use the 'in' keyword: 'access-class <acl-number> in'. The ACL should permit the management subnets and implicitly deny everything else.
Configuring only VTY lines 0-4 and assuming newer devices still only have 5 lines.
Modern Cisco IOS devices support 16 VTY lines (0-15). If you only configure lines 0-4, lines 5-15 retain default settings, which often include 'transport input all' and 'login' with no password. This creates a security hole where an attacker could connect using line 15.
Always apply configuration to all VTY lines using 'line vty 0 15'. This ensures a consistent security posture across all virtual terminal lines.
Thinking VTY sessions are the same as console sessions for all purposes.
Console sessions have direct physical access and can see system messages (like debug output) by default. VTY sessions may not see debug output unless 'terminal monitor' is enabled. Additionally, certain recovery procedures require console access because VTY access may depend on a running configuration that is corrupt.
Understand that VTY is for remote management after the device is operational. For initial configuration and disaster recovery, always use the console port. Use 'terminal monitor' on a VTY session if you need to see debug messages.
Exam Trap — Don't Get Fooled
{"trap":"The exam presents a router configuration with 'line vty 0 4' configured with SSH, but the question asks why a user cannot SSH to the router. The student overlooks that lines 5-15 are not configured and have default 'transport input all' (allowing Telnet and SSH) but also 'no login' or 'password cisco' without 'login' — still, the user is trying SSH, so they might think it should work. However, the trap is that the SSH daemon may be bound to only the configured VTY lines, but more importantly, the RSA keys might not be generated.
The student often picks 'the VTY lines need the 'ip ssh version 2' command' or 'the user is using the wrong protocol' instead of the correct answer.","why_learners_choose_it":"Learners focus on the VTY line configuration that is visible (lines 0-4) and assume it is sufficient. They forget the prerequisite step of generating RSA keys with 'crypto key generate rsa'.
They also may think the issue is that Telnet is allowed on other lines, but since SSH is allowed everywhere, the user should be able to connect. The missing RSA key is a subtle but critical prerequisite.","how_to_avoid_it":"Always remember the three-step checklist for SSH: 1) Generate RSA keys (ip domain-name and crypto key generate rsa), 2) Create a local username, 3) Configure VTY lines with transport input ssh and login local.
If any step is missing, SSH will fail. In exam questions, if you see a router without RSA keys generated, that is almost always the root cause of SSH failure."
Step-by-Step Breakdown
Remote client initiates connection
A network administrator uses an SSH or Telnet client to connect to the device's IP address on port 22 (SSH) or 23 (Telnet). The client sends a TCP SYN packet to start a session. This is the trigger that makes the device look for an available VTY line.
Device receives TCP connection request
The device's IP stack accepts the TCP three-way handshake. The IOS kernel then examines the destination port to determine if it matches a configured transport protocol (e.g., SSH or Telnet) on any VTY line. If the protocol is not allowed, the connection is rejected at this stage.
IOS checks VTY line availability
The operating system scans the list of VTY lines (0-15) to find one that is not currently in use. Each line can be in a state of 'idle', 'active', or 'locked'. If all lines are occupied, the device sends a TCP RST to refuse the connection, and the user sees 'Connection refused' or 'All VTY lines are in use'.
VTY line assignment and authentication trigger
Once an available VTY line is found, the IOS maps the incoming session to that line. The line then activates its configured authentication method. If 'login local' is configured, the device prompts for a username and password, then checks against the local database or AAA server. If only 'login' is set, it prompts for the enable password.
Access control list (ACL) filtering
Before the session proceeds to the CLI prompt, the device checks any 'access-class' ACL applied to the VTY line with the 'in' direction. The source IP of the client is compared against the ACL. If it is denied, the session is immediately terminated. If permitted (or no ACL is configured), the user proceeds to the CLI.
CLI session starts with exec-timeout monitoring
After successful authentication and ACL check, the user is presented with the IOS user EXEC prompt (e.g., Router>). The VTY line starts a timer based on the 'exec-timeout' value. If the user does not input any commands for the set duration, the session is automatically terminated, freeing the VTY line for other users.
User exits the session and VTY line is freed
When the user types 'exit' or 'logout', or the session times out, the VTY line is placed back into an idle state. The line is then available for the next incoming connection. Properly freeing VTY lines is important to prevent session exhaustion.
Practical Mini-Lesson
Understanding VTY lines deeply means going beyond the exam objectives and knowing how they behave in real network operations. As a network professional, you will configure VTY lines on every Cisco device you deploy, from small office routers to large enterprise switches. The configuration process is straightforward, but the security implications are significant.
Let's start with the standard secure configuration for a Cisco device. First, you need an IP domain name and RSA keys for SSH. The commands are: 'ip domain-name example.com' and then 'crypto key generate rsa modulus 2048'. The modulus of 1024 is minimum, but 2048 is preferred for security. Without this step, SSH will not work at all — you will get an error when trying to initiate an SSH session. Next, create a local user: 'username admin secret StrongPassword'. The 'secret' keyword encrypts the password using MD5 (type 5) or SHA-256 in newer IOS. Do not use 'password' with type 0 (plaintext). Then, enter VTY line configuration mode with 'line vty 0 15'. This configures all 16 lines at once. Apply 'transport input ssh' to allow only SSH; if you need Telnet for legacy devices, use 'transport input telnet ssh' but be aware of the security risk. Set 'login local' to use the local username database. Optionally, apply an ACL: 'access-class 10 in' where ACL 10 permits only management subnets (e.g., 'access-list 10 permit 10.0.0.0 0.0.0.255'). Set an exec-timeout: 'exec-timeout 5 0' means 5 minutes and 0 seconds of idle time before disconnection. Finally, set a session limit if needed: 'session-limit 5' to allow only 5 sessions per source IP, helping to prevent brute-force attacks.
One common mistake in production is forgetting to configure the VTY lines for SSH and leaving the default transport input as 'all' or 'none'. The default varies by IOS version, but a new device often has 'transport input none' on all VTY lines, meaning no remote access is possible until you explicitly configure it. That is why the first task after assigning an IP address is often to configure VTY lines. Another mistake is applying an ACL that inadvertently blocks the management subnet itself. Always double-check the ACL logic: permit the subnets that should have access, and deny everything else implicitly. You can test the ACL by using the 'access-list <num> permit host <your-ip>' temporarily and then pinging from your host. If the ping works but SSH fails, check the ACL.
What can go wrong? VTY line exhaustion is a real issue. If multiple administrators leave sessions logged in, or if an attacker opens many connections, the VTY lines can become fully occupied. You can use 'show line' to see the status of each line and 'clear line <line-number>' to forcibly free a session. Also, if the exec-timeout is too long (e.g., 30 minutes), idle sessions will hog lines. Set a reasonable timeout, typically 5-10 minutes.
Another practical issue is that VTY sessions do not automatically see debug output. If you need to see real-time debug messages, use 'terminal monitor' after logging in via SSH. Otherwise, the debug output goes only to the console. This catches many junior engineers off guard.
Finally, remember that VTY configuration is tied to the management interface's reachability. If the management VLAN goes down, VTY access is lost. Use a loopback interface as the management IP and ensure that routing to that loopback is available through redundant paths. In larger networks, placing the management interface in a separate VRF is a best practice.
By mastering VTY configuration and common pitfalls, you will be able to securely manage Cisco devices in virtually any production environment.
Memory Tip
VTY lines are 'Virtual Terminal Yards' — you can have up to 16 trains (sessions) parked simultaneously, each waiting for an engineer (admin) to hop onboard via SSH. Always fence the yard with an ACL and lock the gate with 'login local'.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
200-301Cisco CCNA →Related Glossary Terms
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
An A record is a DNS record that maps a domain name to the IPv4 address of the server hosting that domain.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
A 2-in-1 laptop is a portable computer that can switch between a traditional laptop form and a tablet form, usually by detaching or rotating the keyboard.