Interactive Logon

What Interactive Logon Means in Access Control

Interactive logon is a human-initiated access path, so the security question is not just whether a password is valid, but whether a person should be allowed to reach a console or remote desktop session at all. In practice, it is treated as a higher-risk entry point than machine-to-machine access because it gives a user direct interactive control over a system.

That distinction matters because interactive sessions can execute commands, open files, browse tools and change settings in ways that are harder to constrain than background service activity. When the account is intended for automation, allowing this logon mode undermines the purpose of the account and weakens accountability.

Why Service Accounts Should Not Use It

Service accounts are designed for non-interactive work, so interactive logon usually creates a mismatch between the account’s purpose and its actual use. The result is often broader exposure than intended, especially when a shared account is used by multiple people or when the account has privileged access to support applications or infrastructure.

This is where a control such as the Service Account Security Guide is useful, because the same account governance issues that apply to service identities also apply when a human tries to reuse them for direct sign-in. A separate concern is the human use of non-human identity material, which is exactly the misuse pattern addressed in the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.

How Organisations Detect and Prevent Misuse

Exposure usually starts with policy drift: an account created for an application, integration, database job or scheduled task gradually becomes a convenient backdoor for administrators or support staff. Organisations therefore need to know which accounts exist, which systems they can reach and whether any of them are allowed to log on interactively.

Prevention is typically a combination of host policy, directory policy and privileged access design. At the operating system level, deny interactive logon rights to service accounts; at the access layer, avoid broad role assignment; and at the governance layer, review whether the account is still needed at all. The goal is to keep the account tied to its machine-to-machine purpose, not to let it become an alternate human login.

What Good Practice Looks Like

The strongest practice is to give people their own identities and reserve service accounts for software, integrations and automation. If a person needs temporary elevated access, that access should be granted through a controlled administrative path rather than by borrowing a service account password or token.

That model improves auditability, supports least privilege and makes incident review much clearer because actions can be attributed to a person or a workload, not blurred together inside one shared credential set. It also reduces the chance that a forgotten service account becomes a standing path into critical systems.

Related resources from NHI Mgmt Group

• What is the difference between an Interactive Token and Batch Logon when creating scheduled tasks?
• How should security teams govern interactive MCP components that can trigger tool actions?
• What breaks when interactive components are trusted to send actions directly to agents?
• How should security teams govern interactive UI inside AI agent workflows?