A common example is a script that prompts an administrator for credentials before connecting to a remote system or running a task under another account. Treat it as normal when the context is approved administration, but investigate if it appears in unexpected scripts, scheduled tasks or remote execution flows. Correlate the prompt with the process and target host.
What Get-Credential looks like in an approved admin workflow
A practical Get-Credential example is a PowerShell script that asks an administrator for credentials before using those credentials to open a remote session or run a task as another account. That pattern is normal when the target system and purpose are approved, but it should be treated as a review point when it appears in scheduled jobs, remote execution flows, or scripts that were not expected to require interactive authentication.
In day-to-day administration, Get-Credential is often used as a one-time prompt rather than a stored secret. The value is not the prompt itself, but the fact that the script can defer privilege use until an operator intentionally supplies credentials. That makes it useful for controlled elevation, cross-system administration, and ad hoc access, especially where the operator should remain accountable for the action being taken.
The security question is whether the credential request matches the intended workflow. A normal admin script will usually pair the prompt with a known management target, a predictable tool such as remoting or a service connection, and a clear reason for using alternate credentials. If the prompt appears in a script that launches silently, runs on a timer, or contacts an unfamiliar host, it deserves investigation because the credential capture point may be part of a broader access path rather than a routine admin action.
How to read the prompt in context
Get-Credential is only one step in the chain. The surrounding process matters more than the command name, because the same prompt can support legitimate administration or conceal suspicious credential collection. Good context includes who launched the script, which account executed it, which host it targeted, and whether the resulting authentication was expected for that system and time of day.
Correlating the prompt with the parent process and target host is the quickest way to separate routine use from possible abuse. If the prompt is embedded in a known admin script, linked to a documented remote management task, and executed from a trusted workstation, the event is usually benign. If it is embedded in an unknown script, launched from a user endpoint, or paired with unusual network activity, the prompt becomes a useful indicator that the script may be trying to collect credentials for later reuse.
That distinction is important because credential prompts are often seen as harmless interaction. In practice, the risk is not the dialog box, but the possibility that a script is prompting for secrets in a place where they should not be entered, or for a purpose that is not clearly authorised. The safer interpretation comes from the execution context, not from the text of the command alone.
What practitioners should verify before trusting it
Before accepting a Get-Credential prompt as routine, verify that the script is approved, the destination is expected, and the execution method fits the administration model. If the script is meant to support remote administration, check that the target host, run-as account, and transport path are all consistent with your normal management pattern. If they are not, treat the prompt as a signal to inspect the file, task definition, and execution history.
- Confirm the script owner and business purpose.
- Check whether the prompt occurs interactively or inside automation.
- Review the parent process, command line, and target host.
- Validate that the credentials are being used for a legitimate management action, not copied into an unexpected flow.
For practitioners who want deeper PowerShell-specific context, NHIMG’s PowerShell Security Guide covers common abuse patterns and logging signals that help place a credential prompt in the right operational context. When the issue is less about PowerShell itself and more about secret handling, Secrets Management Guide explains how organisations reduce unnecessary prompting and exposure by centralising secret use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Credential prompts can expose secrets if used in unsafe scripts or workflows. |
| NHI-07 — Long-Lived Secrets | Get-Credential often points to manual secret use that should not become persistent storage. | |
| NHI-10 — Human Use of NHI | The example concerns human-entered credentials driving non-human access workflows. | |
| Recommendation — Limit where credentials are requested and prevent secret exposure in scripts and automation. Prefer short-lived or centrally managed credentials over reusable static secrets. Separate human approval from machine credential use and avoid direct human handling of reusable secrets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The example centers on requesting and using credentials safely in administration flows. |
| AU-2 — Event Logging | Correlating prompt, process, and host depends on audit evidence from execution events. | |
| Recommendation — Manage credential issuance, storage, rotation, and revocation with controlled lifecycle rules. Log credential-use events and retain enough process context to reconstruct the action. | ||
Practitioner Guidance
What to verify: Treat the prompt as expected only when it sits inside a known administrative workflow with an approved target and a traceable operator. If the same pattern appears in a scheduled task, a remote execution chain, or a script you did not expect to handle credentials, verify the file origin and execution history before trusting it.
Common mistake: Teams often review the command in isolation and miss the surrounding behaviour. A benign-looking credential prompt can still be part of credential collection, lateral administration, or an automation path that should not be asking a human for secrets at all.
Practitioner takeaway: The key judgement is not whether Get-Credential is present, but whether the prompt is occurring in the right place, for the right target, and with an execution path that matches approved administration.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org