> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Security best practices
> Protect your DFNS organization with roles, policies, address books, spam filtering, credential rotation, and secure deployment configuration.
DFNS provides multiple layers of security to protect your organization. This guide covers best practices for:
* **Credentials**: Passkeys for humans, protected keys for service accounts
* **Roles**: Control who can do what
* **Policies**: Enforce rules on transactions and sensitive operations
* **Address poisoning protection**: Outbound transfer screening and transaction history warnings
* **Address book**: Recognize your counterparties with human-readable aliases
* **Verified assets**: Filter out spam tokens and suspicious transactions
Already set up? Review your organization against the [security checklist](/guides/security-checklist) for warning signs that are quick to spot and quick to fix.
## Credentials
Every human user should hold three credentials:
* **Main credential**: a [passkey](/core-concepts/passkeys) on the device they work from daily.
* **Backup credential**: a [second passkey](/guides/register-passkey) on a separate device, so losing the main device doesn't mean losing the account. A hardware security key such as a YubiKey is ideal: it is independent of any phone or laptop and can be stored offline in a safe place.
* **Recovery credential**: the [recovery kit](/guides/recover-your-account) issued at registration, stored securely offline, to regain access if both passkeys are lost.
For service accounts, generate keys where they run — a server or secrets manager — and keep no copy on a workstation.
## Browser hardening for the dashboard
The DFNS dashboard runs at `app.dfns.io` in a standard browser. A malicious or compromised browser extension can read and alter any page it runs on — including what an approver sees before they sign. On managed devices, reduce that exposure:
* **Block extensions on the DFNS domain.** In your enterprise browser policy — for example Chrome's [`runtime_blocked_hosts`](https://chromeenterprise.google/policies/#RuntimeBlockedHosts) — block extension content scripts from running on `dfns.io`. Extensions keep working everywhere else but cannot read or modify the dashboard.
* **Allowlist extensions org-wide.** Permit only vetted, business-required extensions instead of letting users install any extension.
* **Use a dedicated or managed browser profile** for dashboard access, isolated from general browsing.
This hardens the browser session, not your keys. Signing always requires a passkey or protected key that an extension cannot produce, so a tampered page cannot forge an approval — this is defense in depth against a manipulated approval surface.
## Policy templates by use case
### Governance policies
The following three policies are the minimum recommended setup for any organization. They reduce the risk of errors and make sure a compromised admin cannot lock you out or escalate privileges unnoticed.
| Policy | Purpose |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Permission Assignment** | Require approval before granting permissions to any user. Prevents a compromised admin from creating fake users with elevated access. |
| **Permission Modification** | Require approval before changing permission sets. Prevents escalation of existing roles. |
| **Policy Modification** | Require approval before changing policies. Ensures your security rules stay in place. |
To create these policies, go to `Org > Policies` and click **New Policy**. Select the appropriate activity type and configure approval groups to require at least a 1-out-of-2 quorum.
### Treasury management
For internal teams managing company wallets with multi-signature approvals:
| Policy | Configuration |
| --------------------------- | ----------------------------------------------------------------------------------- |
| Large transaction approval | `TransactionAmountLimit` at \$100,000 USD with 2-of-3 approver quorum |
| Recipient whitelisting | `TransactionRecipientWhitelist` with known treasury, exchange, and vendor addresses |
| Daily spending cap | `TransactionAmountVelocity` at \$500,000 USD per 24 hours |
| Transaction frequency limit | `TransactionCountVelocity` at 50 transactions per 24 hours |
Use [wallet tags](/core-concepts/policies#using-wallet-tags) to scope policies to specific wallets. Tag treasury wallets with `treasury` and filter policies accordingly.
### Exchange/trading operations
For high-volume operations with exchange integrations:
| Policy | Configuration |
| --------------------- | -------------------------------------------------------------------- |
| Withdrawal velocity | `TransactionAmountVelocity` tuned to expected daily volume |
| Exchange whitelisting | `TransactionRecipientWhitelist` with your exchange deposit addresses |
| High-value approval | `TransactionAmountLimit` for withdrawals above operational threshold |
When using [exchange integrations](/features/exchanges), withdrawals to DFNS wallets may need to be whitelisted in the exchange's address book (e.g., [Kraken](/integrations/exchanges/kraken), [Coinbase Prime](/integrations/exchanges/coinbase-prime)).
### B2B payments
For business payments and vendor disbursements:
| Policy | Configuration |
| ------------------- | -------------------------------------------------------------------------------------------------------- |
| Vendor whitelisting | `TransactionRecipientWhitelist` with approved vendor addresses |
| Tiered approvals | Multiple `TransactionAmountLimit` policies: $10K (1 approver), $50K (2 approvers), \$100K+ (3 approvers) |
| AML screening | `ChainalysisTransactionPrescreening` to screen outbound payments |
## Role templates
Follow the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege): give users only the roles they need for their responsibilities, and don't assign `ManagedFullAdminAccess` to everyone — create custom roles instead. Create these roles in `Settings > Permissions` and assign them based on responsibilities.
### Admin
Full organizational control. Assign sparingly. You can use `ManagedFullAdminAccess` for this role. The list of whitelisted actions is maintained by DFNS and contains all permissions.
### Approver
Reviews and approves transactions. Cannot initiate them.
| Permission | Purpose |
| ----------------------------------------------------- | -------------------------------------- |
| `Policies:Approvals:Approve` | Approve or reject pending transactions |
| `Policies:Approvals:Read` | View pending approvals |
| `Wallets:Read` | View wallet details and balances |
| `Wallets:Transfers:Read`, `Wallets:Transactions:Read` | View transaction details |
### Operator
Day-to-day transaction operations.
| Permission | Purpose |
| ---------------------------------------------------------- | ---------------------------- |
| `Wallets:Read` | View wallets |
| `Wallets:Transfers:Create`, `Wallets:Transfers:Read` | Create and view transfers |
| `Wallets:Transactions:Create`, `Wallets:Transactions:Read` | Create and view transactions |
### Read-only auditor
View-only access for compliance and audit purposes.
| Permission | Purpose |
| ----------------------------------------------------- | ---------------------------------- |
| `Wallets:Read` | View all wallets |
| `Wallets:Transfers:Read`, `Wallets:Transactions:Read` | View all transactions |
| `Policies:Read`, `Policies:Approvals:Read` | View policies and approval history |
| `Auth:Logs:Read` | View audit logs |
### Service account (automation)
For server-to-server API integrations. See [service accounts guide](/guides/developers/service-account).
| Permission | Purpose |
| ----------------------------- | ---------------------------- |
| `Wallets:Read` | Query wallet balances |
| `Wallets:Transfers:Create` | Initiate automated transfers |
| `Wallets:Transactions:Create` | Execute smart contract calls |
Create separate service accounts for different automation tasks, each with minimal required permissions. Service accounts can be [configured as policy approvers](/core-concepts/policies#service-account-approvers) if needed, but keep automation and approval authority separate by default.
## Address poisoning protection
In an address poisoning attack, a scammer:
1. Sends a tiny transaction to your wallet from an address that looks nearly identical to one you regularly send to (matching first and last characters)
2. Hopes you copy that lookalike address from your transaction history when making your next transfer
The dashboard protects you on both sides of this attack.
### Outbound: transfer screening
When you create a transfer in the dashboard, the destination address is screened at the confirmation step:
* A **red warning** appears when the destination closely resembles an address the wallet has sent to before — the signature of an address poisoning attempt. The warning names the resembled address so you can compare.
* A **yellow notice** appears when the wallet has never sent to the destination before, prompting a first-time check.
Screening is advisory: it never blocks the transfer. To enforce blocking, combine it with a [`TransactionRecipientWhitelist` policy](/core-concepts/policies).
Lookalike detection covers EVM networks, Tron, Stellar, XRP Ledger, Bitcoin, Solana, and TON. The first-time-counterparty check runs on every network.
### Inbound: transaction history warnings
In transaction history, any address that is not one of your organization's wallets and not in your address book is marked with a red warning icon. Hovering it shows the full address and a reminder to be careful when copying — so a poisoned deposit's sender stands out instead of blending in with your real counterparties.
Truncated addresses in the dashboard also display characters from the *middle* of the address, selected at hash-based positions. An attacker can cheaply match an address's visible start and end, but not these unpredictable middle characters, so lookalikes remain distinguishable even in truncated form.
**Always verify addresses carefully.** Scammers exploit the fact that users often copy addresses from transaction history without checking every character.
**Best practice:** Add all addresses you regularly interact with to the address book immediately after your first transaction. Known addresses display as their alias, and everything else is flagged.
## Using the address book
The [address book](/guides/address-book) helps you manage blockchain addresses with human-readable aliases. Beyond convenience, it powers the [inbound warnings](#inbound-transaction-history-warnings) above: aliased addresses are recognized, everything else is flagged.
### Address book management
* **Use clear naming conventions**: Include vendor/partner name, purpose, and network (e.g., "acmecorp-payroll")
* **Add descriptions**: Note the business relationship or account purpose
* **Review regularly**: Remove aliases for addresses no longer in use
* **Update promptly**: Add new addresses as soon as you establish new business relationships
### Address book vs policy whitelisting
These are complementary features:
* **Address Book**: Visual convenience and warnings. Helps you recognize addresses in the UI. Does not block transactions.
* **TransactionRecipientWhitelist policy**: Enforcement. Blocks transactions to non-whitelisted addresses (or requires approval).
Use both together: Address Book for awareness and easy identification, policies for enforcement.
## Handling spam and scam tokens
Blockchain addresses can receive unsolicited tokens (airdrops, spam, scam tokens). DFNS provides tools to filter these out.
### Verified assets and transactions
On each wallet page, use the filtering toggles to focus on legitimate assets:
**Assets section:**
* Toggle: "Only show verified assets"
* The "Verified" column indicates which tokens are verified by DFNS
**History section:**
* Toggle: "Only show verified transactions"
* The "Verified" column shows transaction verification status
### What "verified" means
* DFNS maintains a list of verified tokens and contracts across supported networks
* **Verified**: Token is a known legitimate asset
* **Not verified**: Token is not in DFNS's verified list (doesn't necessarily mean malicious, but warrants caution)
Testnet tokens are typically not verified. This is expected behavior.
### Incoming transaction screening with Chainalysis
For additional protection, integrate [Chainalysis KYT](/integrations/aml-kyt/chainalysis) to automatically screen transactions:
* **`ChainalysisTransactionPrescreening`**: Screen outbound transactions before signing
* **`ChainalysisTransactionScreening`**: Flag incoming transactions from suspicious addresses
## Day-to-day security operations
### Reviewing pending approvals
When policies trigger approval requests:
1. Go to `Activity` in the dashboard to see pending approvals
2. Review the transaction details, including recipient address and amount
3. Verify the recipient is in your address book or is otherwise expected
4. Approve or reject the request
The person who initiated a transaction cannot approve it themselves (unless `initiatorCanApprove` is enabled on the policy).
### Monitoring transactions
* Check the "Verified" column in transaction history
* Enable [webhooks](/guides/developers/webhooks) for real-time notifications
* Export transaction history for compliance records (`Wallet > Export`)
### Regular security hygiene
| Task | Frequency |
| ------------------------------------------------------------------------------ | ---------------------------- |
| Review user roles | Quarterly |
| Audit address book entries | Monthly |
| Review policy configurations | Quarterly |
| Test new policies on testnets | Before production deployment |
| Review audit logs | As needed |
| [Rotate credentials](/guides/developers/credential-rotation) | On suspected exposure |
| Run a [disaster recovery drill](/advanced/deployment-models/disaster-recovery) | Yearly |
Before deploying new policies in production, test them on a [testnet](/guides/network-testnets) to ensure they work as expected.
## Next steps
Step-by-step policy creation in the dashboard
Invite users and assign roles
Create and manage address aliases
Set up AML/KYT transaction screening