Start by treating exposed credentials and open management ports as active attack paths, not background hygiene issues. Focus on whether the vendor can be reached through services like SSH, whether those assets are internet-facing, and whether evidence suggests malicious traffic or proxy infrastructure. A strong assessment combines attack surface review, credential exposure checks, and ongoing monitoring for suspicious NetFlow patterns.
What makes exposed credentials and open SSH ports a third-party risk issue?
When a vendor exposes credentials and leaves SSH reachable from the internet, the issue is no longer abstract hygiene. It creates a direct path into the vendor environment and, by extension, into any services, integrations, or data flows the vendor can reach on your behalf. Assessment should therefore focus on exploitability, exposure, and the vendor’s ability to contain a compromise.
A useful assessment starts by asking whether the exposed credential is still valid, whether SSH is actually internet-facing, and whether those assets are segmented from sensitive systems. The presence of either condition can materially increase likelihood of compromise; both together usually mean the vendor has an active attack path that deserves immediate review rather than routine tracking.
How should a buyer evaluate the vendor’s exposure in practice?
Start with asset and access validation. Confirm which systems accept SSH, whether those hosts are intended to be public, and whether the credential can authenticate to production or privileged systems. If the vendor cannot produce a clear inventory of exposed services and credential scope, treat that as a governance failure because the real blast radius is then unknown.
Then test the surrounding controls, not just the headline finding. A strong review looks at credential age, rotation history, MFA or key-based protection where applicable, network restrictions, account ownership, and whether logging can show who used the credential and from where. The practical question is not only “was a secret exposed?” but “what could an attacker do with it today?”
- Verify whether the credential is live, revoked, expired, or shared.
- Check whether SSH is limited by allowlists, jump hosts, or other network controls.
- Confirm whether the exposed endpoint reaches production, admin, or integration systems.
- Review whether the vendor can evidence detection, containment, and rotation within a defined time window.
What evidence should shape the risk decision and follow-up?
For this kind of third-party finding, evidence matters more than reassurance. Suspicious NetFlow, unusual geographies, proxy infrastructure, repeated authentication attempts, or lateral movement indicators are all stronger than a generic statement that “no breach is known.” If the vendor can only offer a verbal denial, the assessment should stay high-risk until telemetry or remediation evidence closes the gap.
Comparable cases in NHIMG’s Guide to the Secret Sprawl Challenge and API Key Management Guide show the same pattern: exposed secrets become real exposure when they are still usable, poorly scoped, or difficult to revoke quickly. For third-party review, that translates into insisting on proof of rotation, revocation, and scope reduction rather than accepting a statement that the issue was “fixed.”
Risk and Threat Considerations
Exposed credentials and open SSH ports are attractive because they can provide direct, low-friction access to a vendor environment. If the vendor uses that access for administration, support, or automation, compromise can quickly become persistence, credential abuse, or downstream access into customer-connected systems.
Failure mechanism: Attackers exploit an internet-facing management service, reuse a leaked credential, or pivot through a weakly monitored host to gain authenticated access that appears legitimate in logs.
Impact: The result can be unauthorized administration, data access, lateral movement, service disruption, or compromise of connected customer systems, especially where the vendor has broad integration rights.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Exposed credentials are the core risk in this vendor assessment. |
| NHI-07 — Long-Lived Secrets | Stale credentials increase the chance that exposed access remains usable. | |
| Recommendation — Rotate leaked secrets, revoke exposed credentials, and verify no live access remains. Replace long-lived credentials with short-lived, tightly scoped secrets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential exposure and rotation are central to deciding whether access is still active. |
| AC-4 — Information Flow Enforcement | SSH reachability and segmentation determine whether compromise can pivot further. | |
| Recommendation — Enforce credential lifecycle controls to revoke, rotate, and expire exposed authenticators. Restrict vendor access paths so exposed services cannot reach sensitive systems. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Third-party access review depends on knowing who can still authenticate and where. |
| Recommendation — Inventory and remove unnecessary vendor access immediately after exposure. | ||
Practitioner Guidance
What to prioritise: Treat reachability and credential validity as the first two gating questions. If the vendor cannot show that exposed access is revoked, rotated, or tightly constrained, the risk should remain open even if no confirmed abuse has been reported.
What to verify: Require evidence of credential rotation, SSH exposure reduction, log review, and containment of any host that accepted the exposed secret. If the vendor cannot correlate access logs to the suspected window, assume the assessment is incomplete.
Decision rule: If the exposed credential can reach production, administration, or customer-connected services, escalate to high severity and demand remediation proof before accepting residual risk. If access is isolated to a non-sensitive enclave with strong monitoring, the issue may be narrower, but it is still a control failure that needs closure.
Practitioner takeaway: The correct assessment is not whether a vendor has “a secret problem,” but whether the exposed secret and open port create a usable path into systems that matter. If they do, treat it as an active third-party attack path until the vendor proves otherwise.
Related resources from NHI Mgmt Group
- How should organisations assess third-party AI risk in vendor contracts?
- How should organisations govern third-party access in a vendor risk policy?
- How can organisations reduce risk from third-party service credentials?
- How should organisations assess third-party risk when vendors touch sensitive workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
