Well, "at rest" means when you only have the access to the database files, you can't get at the data, even when knowing the file structure of MDB files (in this case).
"at rest" refers to the state of the SQL Server not running, being at rest, though that's not the important part, really - the databse file content doesn't change with the status of the service running or not. The reference makes sense only in the oppposite direction, because running SQL Server Service, as normal, and connecting to it, using the databases just as usual with no code changes, you don't need to write decryption routines to get at the actual data.
So this is just protection against someone getting at the hardware but not getting into the service. It would not be surprising, if your customer doesn't even know this is a level of security not protecting against a hacker instrusion by software, which is the more probable way a hacker takes than actually getting into a data center in person, isn't it?
So that security level protects you from guys swapping out drives in the data center. It's good for that case but no more than that.
What I can't tell you is the exact specification of the necessary security level if you'd wanted to offer same security level with DBFs, technically the step to login to SQL Server has the same two times authentication as is necessary by file permissions, so DBFs can be double secured in the same strength as long as besides file permissions the drives used for storge are using certified hardware encryption. Which means when not running Windows and a specific user SID, just 1:1 reading the drive will give you encrypted data only. Whereas when logged in as usual and having the right permissions, you also don't need cryptor or other such tools/DLLs top read the data decrypted, that happens by the hardware controller in conjunction with Windows.
Which also means that VFP+DBF files+Cryptor is a higher level of security than that, by the way. But I guess data protection officers working for authorities qualified to verify a company wouldn't know, recignize or allow this, so you're bound to what laws specify.
I think it's not your goal to use DBFs. Using SQL Server with this level of data at rest security is possible without changing client side code. Once you're connected to SQL Server and pass in a query as usual you also get back the data as usual, not encrypted. At best it's combined with connections using SSL, so the network traffic from SQL Server to clients is also encrypted and you get to the level of end to end encryption.
Not to forget, SQL Server also has features to store data encrypted on top of that general data at rest protection.
With only data at rest protection, the hurdle for hackers is still "just" the login to the data center server (OS level) and then the SQL Server service or the file access permissions (or both). With all their means like listening on a network, hijacking already made connections, etc, etc.
These demamnds are driven by governments, usually, and paint a picture of false/incomplete and wrong understanding, as they enforce very little against the real threats. Encryption at rest is something that I consider important and good for laptops, but they are less helpful for servers that are placed in secure places. So the actual case they protect against are - as said - data center employees able to swap server drives to steal data, more or less. It becomes less important when there is an additional layer of VMs running on servers, which add another level of access and likely also encryption to not have hands on data even encrypted, just by having a swapped out drive.
To protect against ransomware encrypting a file system, for example, already encrypted data does not protect against being encrypted again by the ransomware and thus not accessible also by an SQL Server able to decrypt it's own encryption. So the only protection level against that remains what always was best to recover from any kind of loss: Backups. Also stored remote to protect against the case of local physical damage like fire or water damages.
The topic I guess is data privacy and protection of rights on personal data, for example in medicinical data. It's not a step in the wrong direction, it's just a too small step. Well, the only good news is that as a developer you are not involved in when SQL Server stores its databases with this data at rest protection.
Chriss
