diff --git a/Security-Overview.md b/Security-Overview.md
index b0d20e5..45d8fa6 100644
--- a/Security-Overview.md
+++ b/Security-Overview.md
@@ -3,8 +3,11 @@
 Since SeaweedFS is a distributed system with many volume servers, the volume servers have the risk of being changed without proper access control. We want to have the freedom to place a volume server anywhere we want, with the confidence that nobody can tamper the data. 
 
 We will address the volume servers first. The following items are not covered, yet:
-1. master server http REST services
-1. filer server http REST services
+- master server http REST services
+
+Starting with version 2.84, the Filer HTTP REST services can be secured
+with a JWT, by setting `jwt.filer_signing.key` and
+`jwt.filer_signing.read.key` in `security.toml`.
 
 In summary, here are what can be achieved. 
 
@@ -14,7 +17,7 @@ master | gRPC | secured by mutual TLS
 volume | gRPC | secured by mutual TLS
 filer  | gRPC | secured by mutual TLS
 master | http | "weed master -disableHttp", disable http operations, only gRPC operations are allowed.
-filer  | http | "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE.
+filer  | http | **Before version 2.84:** "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.<br /><br /> **Starting with version 2.84**: secured by JWT, by setting `jwt.filer_signing.key` and `jwt.filer_signing.read.key` in `security.toml`. **This now works with the [[Amazon S3 API]].**
 volume | http write | set `jwt.signing.key` in `security.toml` in master and volume servers to check token for write operations
 volume | http read | unprotected, but url is not guessable
 
@@ -67,4 +70,19 @@ JWT Summary:
 The volume server can also check JWT for reads. This mode does not work with `weed filer`. But this could be useful if the volume server is exposed to public and you do not want anyone to access it with a URL, e.g., paid content.
 
 * To enable it, set the `jwt.signing.read.key` in `security.toml` file.
-* To obtain a JWT for read, the JWT can be read from the response header `Authorization` of  `http://<master>:<port>/dir/lookup?fileId=xxxxx&read=yes`.
\ No newline at end of file
+* To obtain a JWT for read, the JWT can be read from the response header `Authorization` of  `http://<master>:<port>/dir/lookup?fileId=xxxxx&read=yes`.
+
+# Securing Filer HTTP with JWT
+
+To enable JWT-based access control for the Filer,
+
+1. generate `security.toml` file by `weed scaffold -config=security`
+2. set `jwt.filer_signing.key` to a secret string - and optionally `jwt.filer_signing.read.key` as well to a secret string
+3. copy the same `security.toml` file to the filers and all S3 proxies.
+
+If `jwt.filer_signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `jwt.filer_signing.key`.
+
+If `jwt.filer_signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `jwt.filer_signing.read.key`.
+
+The S3 API Gateway reads the above JWT keys and sends authenticated
+HTTP requests to the filer.