What is the difference between protecting sensitive data with named credentials and storing it in custom metadata or encrypted fields?

The right storage pattern depends on what the secret is for. Named credentials are suited to external service authentication, protected custom metadata or settings are better for package level secrets such as API keys, and encrypted custom fields fit sensitive user data like PII or payment details. The key decision is whether the value is operational secret material or application data.

How the storage choice changes the security model

Named credentials, custom metadata, custom settings, and encrypted fields solve different problems, so the right pattern depends on what you are protecting and how the value is used. If the value is an operational secret that must authenticate to another system, you want a mechanism built for credential handling and rotation. If the value is application configuration or sensitive business data, the storage model should match that use case instead of forcing everything into one bucket.

Named credentials are designed to hold connection details and authentication material for outbound integrations, so they belong in the path where the platform actually needs to reach an external service. That makes them a better fit than generic data storage when the secret is part of runtime access rather than business content. For broader secret handling and lifecycle patterns, the Secrets Management Guide explains why centralisation, rotation, and secretless patterns matter once a value starts behaving like a credential.

Custom metadata or protected settings are better when the value is configuration, package-level input, or a deployment-time secret that the application needs to read without treating it as user data. That distinction matters because metadata is usually about control-plane behavior, not record-level confidentiality. When teams blur the line, they often end up using a storage method that is convenient for developers but awkward for governance, rotation, or packaging.

Encrypted custom fields fit a different category again: they are for sensitive data elements that belong to a record, such as personal data, financial attributes, or other fields that should stay with the object while still being protected at rest. That makes them appropriate for data protection, but not for secrets that need to be presented to an external system as an authentication factor. For API-style secrets and token handling, API Key Management Guide is a better companion because it focuses on scoping, rotation, revocation, and leak response.

Where teams commonly pick the wrong pattern

The most common mistake is storing operational secrets as if they were ordinary application data. That creates confusion around who can read the value, when it should rotate, and whether the platform is using it as a credential or merely storing it. The second mistake is overusing encrypted fields for values that need to be supplied to an integration, which can make the application harder to operate and may still leave the value copied into logs, exports, or temporary variables.

Another failure mode is assuming that “protected” means “safe for any sensitive thing.” Protection is not the same as fit-for-purpose storage. A secret that must be consumed by an integration needs lifecycle handling, revocation paths, and clear ownership, while sensitive data needs access controls and field-level protection aligned to the record or object model. The wrong storage choice often increases the number of places the value appears, which widens the blast radius if it is ever exposed.

For secrets that need lifecycle discipline, RFC 6749: The OAuth 2.0 Authorization Framework is useful because it shows how machine-to-machine access is supposed to be structured rather than improvised with stored shared secrets. When a value is not an integration credential, that same structure is unnecessary overhead.

How to decide which bucket the value belongs in

Start by asking what the value does in the system. If it authenticates an outbound connection, or if losing it would let another system impersonate your application, treat it as credential material and keep it in a credential-oriented store. If it changes how the application behaves but does not itself prove identity, it usually belongs in configuration. If it is data about a person or transaction, it belongs in a data field with the right encryption and access controls.

A practical rule is to classify by function, not by sensitivity alone. Highly sensitive values can still belong in different storage models depending on whether they are operational secrets or user data. That is why a package secret, an API key, and a customer’s payment detail should not all be handled the same way even though all three are sensitive.

If the value can be rotated independently of the record it supports, that usually points toward a secret-management pattern. If it must persist as part of the record lifecycle, that usually points toward an encrypted field. If it is a package or deployment setting that should remain hidden from casual inspection but does not function as a credential, protected metadata is often the cleaner choice.

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 OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle handling for secrets and authenticators used to access systems.
	AC-6 — Least Privilege	Supports limiting access to sensitive fields and stored secrets to only needed principals.
Recommendation — Use IA-5 to manage issuance, rotation, and revocation of stored credentials. Apply AC-6 to restrict who can read or use stored sensitive values.
OWASP ASVS	V11 — Cryptography	Applies when sensitive fields require encryption at rest and protected key handling.
	V10 — OAuth and OIDC	Relates to credentialed outbound access patterns and token-based integration design.
Recommendation — Use V11 to encrypt sensitive fields and protect the keys that secure them. Use V10 to prefer token-based integration patterns over ad hoc shared secrets.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Directly addresses exposure of stored secrets and keys used by integrations.
Recommendation — Apply NHI-02 to prevent secret leakage from storage, logs, and code.

Practitioner Guidance

What to verify: Verify whether the value is used for authentication, configuration, or record-level sensitive data before choosing the storage pattern. The best test is operational: if the application would fail to connect without the value, treat it as secret material; if the application would still connect but behave differently, treat it as configuration or data.

Decision rule: If the value grants access, prioritise a credential-oriented mechanism with rotation and revocation. If it describes application behavior or deployment state, use protected metadata or settings. If it is sensitive user information, use encrypted fields and keep read access tightly aligned to the data model.

Common mistake: Do not pick the storage method because it is easiest to implement in the short term. The wrong choice usually shows up later as weak rotation, unclear ownership, or data being copied into places that were never meant to hold secrets.

Practitioner takeaway: The key judgement is whether the value is being used as an operational secret or as application data, because that distinction should drive storage, rotation, and access design.