diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..56c63fd
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,118 @@
+# Security Considerations
+
+---
+
+## **1. Overview**
+This document analyzes the security of passwords generated by the application, which uses the following parameters:
+- **Length**: 32 characters
+- **Character set**: Uppercase letters (`A-Z`), lowercase letters (`a-z`), digits (`0-9`)
+- **No special characters** (equivalent to `apg -a 1 -m 32 -n 1 -M NCL`)
+
+---
+
+## **2. Keyspace Analysis**
+### **2.1. Character Set and Length**
+- **Character set size**: 26 (uppercase) + 26 (lowercase) + 10 (digits) = **62 possible characters per position**.
+- **Password length**: 32 characters.
+
+### **2.2. Total Keyspace**
+The total number of possible passwords is calculated as:
+\[
+62^{32} \approx 1.46 \times 10^{57}
+\]
+This means there are **1.46 decillion** possible combinations.
+
+---
+
+## **3. Brute-Force Resistance**
+### **3.1. Average Number of Guesses**
+On average, an attacker would need to try half of the keyspace to guess the correct password:
+\[
+\frac{62^{32}}{2} \approx 7.3 \times 10^{56} \text{ attempts}
+\]
+
+### **3.2. Time to Crack on Modern Hardware**
+| Hardware          | Hashes per Second | Time to Exhaust Keyspace       |
+|-------------------|-------------------|--------------------------------|
+| Modern CPU        | 10 billion        | \(7.3 \times 10^{46}\) seconds | \(\approx 2.3 \times 10^{39}\) years |
+| Modern GPU        | 100 billion       | \(7.3 \times 10^{45}\) seconds | \(\approx 2.3 \times 10^{38}\) years |
+
+**Note**: Even with **massive parallelization** (e.g., botnets or supercomputers), brute-forcing a 32-character password from this keyspace is **practically infeasible**.
+
+---
+
+## **4. Comparison with Shorter Passwords**
+| Length | Keyspace (62 Characters) | Average Guesses | Time on GPU (100 GigaHashes/s) |
+|--------|--------------------------|-----------------|-------------------------------|
+| 16     | \(4.7 \times 10^{28}\)    | \(2.35 \times 10^{28}\) | ~74 years                      |
+| 24     | \(1.3 \times 10^{43}\)    | \(6.5 \times 10^{42}\) | ~2.1 million years            |
+| 32     | \(1.46 \times 10^{57}\)   | \(7.3 \times 10^{56}\) | ~2.3 trillion years            |
+
+---
+
+## **5. Threat Model**
+### **5.1. Brute-Force Attacks**
+- **Conclusion**: Brute-force attacks are **not a viable threat** for 32-character passwords.
+- **Mitigation**: Ensure the system enforces **rate-limiting** to prevent automated guessing.
+
+### **5.2. Social Engineering and Side-Channel Attacks**
+- **Social Engineering**: Phishing, keyloggers, or shoulder surfing are **more realistic threats** than brute-force attacks.
+- **Side-Channel Attacks**: Timing attacks or power analysis could theoretically reduce security if the password verification is poorly implemented.
+  - **Mitigation**: Use **constant-time comparison** functions for password verification.
+
+### **5.3. Password Storage**
+- **Hashing**: Always store passwords using **strong, adaptive hashing algorithms** like:
+  - **Argon2** (recommended for new systems)
+  - **bcrypt** or **PBKDF2** (with high work factors)
+- **Salting**: Use a **unique salt per password** to prevent rainbow table attacks.
+
+---
+
+## **6. Practical Recommendations**
+### **6.1. For Users**
+- **Password Managers**: Encourage the use of password managers to store and manage generated passwords.
+- **Multi-Factor Authentication (MFA)**: Always enable MFA where possible to add an extra layer of security.
+
+### **6.2. For Developers**
+- **Rate Limiting**: Implement rate limiting on authentication endpoints to slow down brute-force attempts.
+- **Secure Transmission**: Ensure passwords are transmitted over **TLS/SSL** to prevent interception.
+- **Password Policies**: Enforce policies that discourage password reuse and encourage regular updates.
+
+### **6.3. For DFIR and Incident Response**
+- **Logging and Monitoring**: Log failed login attempts and monitor for unusual activity.
+- **Incident Response Plan**: Have a plan in place for compromised accounts, including forced password resets and user notification.
+
+---
+
+## **7. Additional Considerations**
+### **7.1. Extended Character Set**
+If special characters are included (e.g., `!@#$%^&*`), the keyspace increases to:
+\[
+72^{32} \approx 1.9 \times 10^{60}
+\]
+This further improves security but is **not necessary** for most use cases given the already massive keyspace.
+
+### **7.2. Entropy Calculation**
+The **entropy** of a 32-character password from a 62-character set is:
+\[
+\log_2(62^{32}) \approx 192.6 \text{ bits}
+\]
+This exceeds the **128-bit security level** recommended by NIST for cryptographic applications.
+
+---
+
+## **8. Conclusion**
+The passwords generated by this application are **extremely secure** against brute-force attacks due to their length and character diversity. The primary risks lie in **human factors** (e.g., phishing, reuse) and **implementation flaws** (e.g., weak hashing, lack of rate limiting).
+
+For **DFIR and high-security environments**, combine these passwords with:
+- **Multi-Factor Authentication (MFA)**
+- **Regular audits** of authentication logs
+- **User education** on social engineering risks
+
+---
+
+## **9. References**
+- [NIST Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) (Digital Identity Guidelines)
+- [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
+- [Argon2: The Memory-Hard Function for Password Hashing](https://github.com/P-H-C/phc-winner-argon2)
+