| Feature | ntkDesktop | Generic Sync Agent | VPN + File Share |
|---|---|---|---|
| Client-side encryption | ✓ Always. AES-256-GCM per file. | ✗ Provider-side or none | ✗ Transport only (TLS) |
| Zero plaintext at rest | ✓ Structural guarantee | ✗ Provider can access files | ✗ Files stored plaintext on share |
| Windows CFAPI native | ✓ Full Shell integration | ~ Often virtual drive hacks | ✗ UNC path, no placeholder API |
| On-demand hydration | ✓ CfCreatePlaceholders | ~ Varies by product | ✗ Full mount required |
| Zero-trust policy (dABAC) | ✓ AND-of-OR, deny-by-default | ✗ ACL/RBAC if any | ~ Network-level only |
| Offline access | ✓ Cached shards + local keys | ~ Offline mode varies | ✗ Requires VPN connectivity |
| Provider-agnostic | ✓ 6 providers, same API | ~ Usually single vendor | ✓ Any SMB share |
| IDA shard dispersal | ✓ k-of-n configurable | ✗ Single provider only | ✗ Not applicable |
| Device-bound auth tokens | ✓ DPoP + JWKS rotation | ~ Bearer tokens typical | ✗ Domain credentials |
| Shell context menu | ✓ IStorageProviderUICommand | ~ Shell extension varies | ✗ None |
| Structured audit logs | ✓ JSONL, fixed field schema | ~ Varies | ~ Windows event log |
| Open source | ✓ Full source available | ✗ Typically proprietary | ✓ OS file server |
✓ Supported
~ Partial
✗ Not supported
Encryption at the boundary, not the edge.
Generic sync agents that rely on provider-side encryption grant the provider read access to your data by design. VPN-based approaches protect the transport layer but leave files stored in plaintext at the destination. ntkDesktop's position is that the only party who should be able to decrypt a file is the enrolling device — at all times.