TL;DR: Arcon says zero-trust vaulting for passwords, SSH keys, certificates and confidential files depends on granular permissions, time-bound access, automatic deletion and auditability, because secure storage alone does not stop misuse across increasingly complex enterprise estates. Governance is the real control plane: if sharing, ownership transfer and revocation are inconsistent, the vault becomes another policy boundary with gaps.
At a glance
What this is: Arcon describes a cloud-native vault model for storing and sharing secrets and confidential files with least-privilege access, time-bound access, deletion controls and audit logging.
Why it matters: IAM, PAM and NHI teams should care because the article ties vault security to governance controls that determine whether credentials and sensitive files stay contained after they are shared.
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
👉 Read Arcon's analysis of zero-trust vault controls for secrets and file sharing
Context
Zero-trust vaulting is the discipline of controlling how secrets and sensitive files are stored, shared, revoked and audited rather than assuming the application layer will enforce safety on its own. In this article, Arcon frames the problem around passwords, SSH keys, certificates and confidential files moving through increasingly complex enterprise environments.
That matters for NHI governance because vaults now sit at the centre of machine credentials, privileged access and controlled file exchange. When access permissions, ownership transfer, download restrictions and deletion rules are inconsistent, the vault stops being a containment boundary and becomes another identity control surface with lifecycle gaps.
The article also points to a broader convergence between secrets management and file governance. The same policy model has to protect static secrets, dynamic secrets and shared documents if organisations want zero-trust behaviour to hold beyond the first access request.
Key questions
Q: How should teams govern shared vault access when internal and external users collaborate?
A: Use object-level permissions, explicit ownership and short-lived access so a shared vault does not become a permanent distribution channel. Cross-domain collaboration needs the same lifecycle discipline as privileged access: every request should be tied to a business purpose, every grant should be revocable, and every transfer should preserve accountability.
Q: Why do zero-trust vaults need time-bound access for secrets and files?
A: Because stored data can remain safe at rest while still being overused after the work is done. Time-bound access limits reuse, reduces blast radius and prevents a shared secret or file from outliving the task that justified access. Without expiry, the vault becomes a durable entitlement store rather than a governed control.
Q: What breaks when vault ownership and download restrictions are too loose?
A: Accountability breaks first, followed by revocation. If ownership can be transferred without a clear entitlement change, or downloads can happen without strong restrictions, teams lose track of who can still act on the object. That creates uncontrolled reuse paths even when the vault itself is encrypted and audited.
Q: Should organisations pair vault logging with privileged access management?
A: Yes. Vault logs show what happened, but PAM explains whether the access was appropriate and who authorised it. Pairing the two gives security teams a complete control story for high-risk secrets, especially when the vault holds passwords, SSH keys, certificates or other credentials that enable privileged action.
Technical breakdown
Granular access controls in vault-based sharing
A vault only behaves like a zero-trust control when each access decision is scoped to a specific user, object and purpose. Granular permissions, ownership transfer controls and download restrictions reduce the chance that shared files or secrets become broadly reusable after the original business need has passed. In identity terms, the vault is acting as an enforcement point for least privilege, but only if the entitlement model is kept tight enough to limit downstream reuse. When access is granted too broadly, the vault becomes a repository of durable access paths rather than a controlled exchange point.
Practical implication: review vault entitlements as object-level access decisions, not as general repository permissions.
Time-bound access and automatic deletion for secrets
Time-bound access and automatic deletion are the mechanisms that turn vault storage into a lifecycle control rather than a static archive. For secrets, the issue is not only whether they are encrypted at rest, but whether they remain usable after the task, change window or collaboration period ends. Dynamic secrets management matters because static credentials, tokens and keys can outlive their intended purpose and expand blast radius. A vault that supports expiry and deletion narrows the window in which a credential can be reused or exfiltrated.
Practical implication: align secret TTLs and deletion rules to business use cases, not to storage convenience.
Audit logs, monitoring and PAM integration
Real-time audit logs and monitoring create accountability, but they only work when paired with a privileged access model that can explain who requested access, who approved it and what was done with it. Integration with PAM is important because vaults often hold the credentials that unlock high-risk operational activity. Without that linkage, security teams may see storage events but miss the access governance context around them. The technical boundary here is clear: logging records what happened, while PAM and identity controls determine whether it should have happened in the first place.
Practical implication: correlate vault audit events with privileged access records before treating logs as sufficient control evidence.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Zero-trust vaulting only works when storage is treated as an identity control plane. The article is really about governance over secrets, certificates and files, not about storage mechanics alone. Once a vault becomes the system where access, sharing and deletion are decided, it inherits the same lifecycle pressure as PAM and NHI governance. Practitioners should stop treating the vault as a passive container and start treating it as an access boundary.
Ownership transfer and download restrictions are the real differentiators in shared vault workflows. Collaboration breaks down when a file or secret can move between owners, domains and users without a clear entitlement change. That is not just a usability issue, it is a governance issue because accountability becomes detached from the object being shared. The practical conclusion is that cross-domain sharing must preserve ownership and revocation semantics, not merely transport data.
Dynamic secrets management reduces reuse risk in a way static vault storage cannot. Static credentials in a vault may be protected, but they still create reuse potential if expiry and rotation are weak. Dynamic issuance changes the governance burden from protecting a stored secret to governing its short-lived usefulness. For NHI programmes, that shift matters because the control objective moves from safekeeping to constrained validity.
Vault misconfiguration is a lifecycle failure, not just an access control failure. The article emphasises least privilege, time-bound access and deletion, which means the control gap is not a single permission check but the absence of end-to-end governance. If access can be granted, shared and retained beyond its intended use, the vault is carrying unresolved privilege. Practitioners should evaluate the full secret lifecycle, from upload through revocation.
Cross-domain vault sharing exposes the same trust problem seen in other identity domains. External collaboration is only safe when the sharing boundary is explicit, verified and monitored. This is where vault governance meets zero trust: the system must verify every request, not assume trust because the data already sits inside the platform. The implication for teams is to extend identity policy to the object itself, not only to the user session.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl now needs lifecycle governance, not just storage policy. Vault design decisions are increasingly about how long a secret can live, who can transfer it and what happens when the task ends. That means NHI programmes should evaluate vaults as part of identity lifecycle management rather than as a standalone repository control.
Cross-domain sharing is where vault governance gets tested. The moment secrets or files move outside a single trust domain, object ownership, approval context and revocation become more important than encryption alone. Organisations that do not model those transitions will keep discovering that secure storage did not solve secure use.
Dynamic secrets change the control objective from protection to expiration. Once credentials are short-lived, the operational question becomes whether issuance, monitoring and deletion all work together. That is a better zero-trust test than asking whether the vault can simply hold sensitive material safely.
For practitioners
- Tighten object-level permissions Map each vault object to a specific owner, requester and purpose, then remove broad folder-level access where the business task only requires item-level sharing.
- Enforce time-bound secret validity Set expiry and automatic deletion for secrets and shared files so access ends with the intended task, change window or collaboration period.
- Separate collaboration from persistence Use distinct controls for upload, share, transfer and download so external collaboration does not create permanent reuse paths for confidential content.
- Correlate vault events with PAM Require vault audit logs to be reviewed alongside privileged access records whenever the vault stores passwords, SSH keys, certificates or other high-risk credentials.
- Define allowed file types Whitelist the file classes that the vault should accept and automatically restrict everything else to reduce accidental exposure through unsupported content.
Key takeaways
- The article shows that vault security is only as strong as the lifecycle rules around sharing, transfer and deletion.
- The main risk is not storage alone but reusable access paths that persist after a task or collaboration ends.
- Teams should treat vaults as identity control points and connect them to PAM, time-bound access and revocation processes.
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 and MITRE ATT&CK address 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-01 — Improper Offboarding | Time-bound deletion and transfer controls address secrets that outlive their intended owner or purpose. |
| NHI-05 — Overprivileged NHI | Granular permissions are the article's core control against excessive access to stored secrets and files. | |
| NHI-07 — Long-Lived Secrets | Dynamic secrets and automatic deletion directly counter static credentials that remain usable too long. | |
| Recommendation — Tie vault ownership changes and deletion rules to offboarding so secrets do not outlive accountability. Review vault permissions for overbroad access and reduce each entitlement to the minimum needed. Replace persistent credentials with short-lived secrets and enforce expiry for all shared vault assets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on managing passwords, SSH keys and certificates across their lifecycle. |
| Recommendation — Apply authenticator lifecycle controls to rotate, expire and revoke stored credentials on schedule. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed or over-shared secrets create the same paths adversaries use for credential access and movement. |
| Recommendation — Map vault-exposed credentials to credential access and lateral movement detections in your telemetry. | ||
Key terms
- Zero-trust vaulting: A vaulting model that treats stored secrets and files as continuously governed assets rather than trusted content once they are inside a repository. Access, sharing, deletion and auditability are enforced per request, per object and per lifecycle stage so the vault does not become a permanent reuse path.
- Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
- Ownership Transfer: Ownership transfer is the point at which an extension changes hands, either through sale, account compromise, or developer handoff. It matters because the extension can keep the same name, rating, and install base while becoming a materially different security object after the transfer.
- Cross-Domain Sharing: Cross-domain sharing is the controlled exchange of sensitive files or secrets between users from different organisational or trust boundaries. It requires separate verification, scoped permissions, and strong audit trails because the recipient is outside the native identity domain.
What's in the full article
Arcon's full article covers the operational detail this post intentionally leaves for the source:
- Feature-level handling of secure file sharing and ownership transfer inside My Vault
- The practical behaviour of time-bound access and automatic deletion for sensitive assets
- How the DRM tool synchronises files and folders into the vault workflow
- The specific ways cross-domain sharing uses 2FA and download restrictions
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org