diff --git a/docs/api/deprecations.md b/docs/api/deprecations.md
index 84c0300543..136d70778e 100644
--- a/docs/api/deprecations.md
+++ b/docs/api/deprecations.md
@@ -83,7 +83,7 @@ migrate to your own custom API.
 
 First, you'll need to define a new Utility API reference. If you're only using
 the API for sign-in, you can put the definition in `packages/app/src/apis.ts`.
-However, if you need to access your auth API inside plugins you you'll need to
+However, if you need to access your auth API inside plugins you'll need to
 export it from a common package. If you don't already have one, we recommend
 creating `@internal/apis` and from there exporting the API reference.
 
diff --git a/docs/integrations/azure-blobStorage/discovery.md b/docs/integrations/azure-blobStorage/discovery.md
index f0953815c2..f0019a5c01 100644
--- a/docs/integrations/azure-blobStorage/discovery.md
+++ b/docs/integrations/azure-blobStorage/discovery.md
@@ -61,7 +61,7 @@ the Azure catalog plugin:
 yarn --cwd packages/backend add @backstage/plugin-catalog-backend-module-azure
 ```
 
-Then updated your backend by adding the following line:
+Then update your backend by adding the following line:
 
 ```ts title="packages/backend/src/index.ts"
 backend.add(import('@backstage/plugin-catalog-backend'));
diff --git a/docs/integrations/azure/discovery.md b/docs/integrations/azure/discovery.md
index 0eafc938a2..67d70c7f6d 100644
--- a/docs/integrations/azure/discovery.md
+++ b/docs/integrations/azure/discovery.md
@@ -97,7 +97,7 @@ the Azure catalog plugin:
 yarn --cwd packages/backend add @backstage/plugin-catalog-backend-module-azure
 ```
 
-Then updated your backend by adding the following line:
+Then update your backend by adding the following line:
 
 ```ts title="packages/backend/src/index.ts"
 backend.add(import('@backstage/plugin-catalog-backend'));
diff --git a/docs/integrations/azure/org.md b/docs/integrations/azure/org.md
index 92f3f9c12a..7bd93f38b3 100644
--- a/docs/integrations/azure/org.md
+++ b/docs/integrations/azure/org.md
@@ -41,7 +41,7 @@ catalog:
 For large organizations, this plugin can take a long time, so be careful setting low frequency / timeouts and importing a large amount of users / groups for the first try.
 :::
 
-Finally, updated your backend by adding the following line:
+Finally, update your backend by adding the following line:
 
 ```ts title="packages/backend/src/index.ts"
 backend.add(import('@backstage/plugin-catalog-backend'));
diff --git a/docs/integrations/ldap/org.md b/docs/integrations/ldap/org.md
index 8adc81184a..22a843009f 100644
--- a/docs/integrations/ldap/org.md
+++ b/docs/integrations/ldap/org.md
@@ -40,7 +40,7 @@ catalog:
           timeout: PT15M
 ```
 
-Finally, updated your backend by adding the following line:
+Finally, update your backend by adding the following line:
 
 ```ts title="packages/backend/src/index.ts"
 backend.add(import('@backstage/plugin-catalog-backend'));
diff --git a/docs/overview/threat-model.md b/docs/overview/threat-model.md
index 60f22a374c..5c33c5f8e6 100644
--- a/docs/overview/threat-model.md
+++ b/docs/overview/threat-model.md
@@ -30,7 +30,7 @@ This section assumes that you are using the
 
 Backstage is primarily designed to be deployed in a protected environment rather than being exposed to the public internet. From a confidentiality and integrity perspective, Backstage is designed to protect against unauthorized access to data and to ensure that data is not tampered with. However, Backstage does not provide more than rudimentary protection against denial of service attacks, and it is the responsibility of the operator to ensure that the Backstage deployment is protected against such attacks. A common and recommended way to protect a Backstage deployment from unauthorized access is to deploy it behind an authenticating proxy such as AWS’s ALB, GCP’s IAP, or Cloudflare Access.
 
-Users that are signed-in in to Backstage generally have full access to all information and actions. If more fine-grained control is required, the [permissions system](../permissions/overview.md) should be enabled and configured to restrict access as necessary.
+Users that are signed in to Backstage generally have full access to all information and actions. If more fine-grained control is required, the [permissions system](../permissions/overview.md) should be enabled and configured to restrict access as necessary.
 
 An operator is responsible for protecting the integrity of configuration files as it may otherwise be possible to introduce vulnerable configurations, as well as the confidentiality of configured secrets related to Backstage as these typically include authentication details to third party systems.