Type 2 Interactive Logon

What Type 2 Interactive Logon Means in Windows

Type 2 interactive logon is the local, console-based sign-in path Windows uses when a user sits at a machine or opens a desktop session. The important security point is that Windows builds an access token for that session, and that token becomes the basis for what the user can do locally, including which privileges and group memberships are available.

This makes type 2 logons different from remote or service-style logons because the session is tied to a human interactive desktop context rather than a background process or network connection.

Why the Interactive Token Matters

An interactive logon is not just a login event, it is the moment Windows defines the session's authority. That token carries the user's security context, so any privilege assigned to the account, inherited through group membership, or granted by local policy can become active in that desktop session. If the session belongs to an administrative account, the practical blast radius is much larger than for a standard user.

For defenders, the token is the bridge between authentication and local authorization. If an account is allowed to log on interactively, it can use the machine directly, which is why workstation and server console access is a sensitive control boundary.

Where Type 2 Appears in Windows Logging

Security teams usually see type 2 in Windows logon telemetry, especially event 4624 for successful logons. It is one of the core values analysts use to distinguish a console sign-in from network, batch, service, or remote interactive activity, and that distinction matters when reconstructing how a user or intruder gained a session.

Type 2 is often useful in investigations because it can confirm whether activity came from an actual local desktop session rather than a lateral movement path. That makes it a practical clue when you are separating hands-on keyboard access from remote authentication or service execution.

For a deeper event-by-event view of Windows sign-in telemetry, see Windows logon types and authentication events.

Access Control and Identity Security Implications

Type 2 interactive logon becomes especially important when accounts are overprivileged, shared, or used outside their intended role. A local console session can expose cached credentials, mapped drives, saved tokens, and administrative tools, so the logon type is not just an audit label, it is a signal about where privileged work is happening.

Because interactive sign-in gives a user direct access to the desktop, it also makes misuse easier to hide if organisations do not separate human logons from non-human or automated access patterns. That is why local interactive use by accounts that should only run services or integrations is a governance concern, not just an event-log detail.

Windows access-token behaviour is closely tied to token abuse and privilege escalation analysis. If you need to understand how session tokens get misused after logon, review MITRE ATT&CK T1134 Access Token Manipulation and MITRE ATT&CK T1078 Valid Accounts Guide.

How Defenders Use It in Detection and Investigation

Type 2 logons are useful in threat hunting because they help answer a simple but critical question: who actually sat at the keyboard? When investigators see unexpected administrative action, a type 2 logon can help confirm local access, while the absence of one can push the investigation toward remote access, credential replay, or service-based abuse.

In practice, analysts correlate logon type with adjacent signals such as elevated token creation, explicit credential use, or suspicious authentication chains. That combination helps separate routine desktop use from attacker activity that piggybacks on legitimate sessions.

For broader Windows event correlation and logon context, see Windows Event Log Guide, and for identity abuse patterns that often follow valid sign-in, see Pass-the-Hash and Pass-the-Ticket Guide.

Risk and Threat Considerations

Type 2 interactive logon matters most when local sign-in rights are broader than they should be. If privileged or shared accounts can open a console session, an attacker who obtains those credentials can move from authentication to direct hands-on control of the endpoint or server.

Failure mechanism: The account logs on interactively, Windows builds a session token with local authority, and the attacker inherits whatever local rights that token carries, including access to administrative tools, files, and cached secrets.

Impact: The result can be privilege abuse, persistence on the host, theft of additional credentials or keys, and easier post-compromise activity because the attacker is operating inside a real desktop session.

Practitioner Guidance

Why practitioners should care: Type 2 should be treated as a policy boundary, not just an event code. If a role does not need console access, do not let the account sign in locally, especially where the account is privileged, shared, or used for administration. That keeps the interactive desktop from becoming an unnecessary trust path.

What to watch for: Investigate unexpected type 2 logons on servers, admin workstations, and systems where interactive use is unusual. Also watch for service-style accounts or operational accounts that suddenly appear in local sign-in telemetry, because that often signals misuse or broken separation between human and non-human access.

Related resources from NHI Mgmt Group

• Guide: Service Account Security Guide
• What is the difference between an Interactive Token and Batch Logon when creating scheduled tasks?
• When is Logon Type 10 logged?
• Which attacks show up in Logon Type 10?
• How does Logon Type 10 work?